[ANSI-Smalltalk] re: array creation syntax (was: expressing method signatures)

[Eliot Miranda]

On Mon, Mar 24, 2008 at 6:18 PM, Andres Valloud <andres.valloud at gmail.com>
wrote:

> Eliot,
>
> Re: the Bezier2Segment... if I remember correctly, the {} syntax creates a
> literal at compile time.  Is that so?  Or is the array created every time
> execution goes over {}?
>
> In the case of Bezier2Segment, what I think is at times missing from
> consideration is what is usually done with such arrays... do: aBlock?
> Because if so, it would be cheaper (and *sometimes* clearer) to do:
>
> Bezier2Segment>>ellipseSegmentsDo: aBlock
>
>   aBlock
>     value: seg1a;
>     value: seg1b;
>     value: seg2a;
>     value: seg2b;
>     value: seg3a;
>     value: seg3b;
>     value: seg4a;
>     value: seg4b


Um, semicolons aren't what you mean.  You want a
Closure>>value:value:value:value:value:value:value:value: method (right?),
and there isn't one.  You have to use valueWithArguments:.  But there isn't
even an ArrayedCollection class>>with:with:with:with:with:with:with:with:
method to construct one with(*).  So once again a brace construct is the
most convenient way to implement
Closure>>value:value:value:value:value:value:value:value:.

(*) at least you can write ArrayedCollection
class>>with:with:with:with:with:with:with:with:.  You can't write
Closure>>value:value:value:value:value:value:value:value:value: directly
because it would be a primitive and either an 8-arg primitive may not be
available or a varargs primitive may not accept more than 3 arguments.  If
you write it in terms of valueWithArguments: you still need Array
class>>with:with:with:with:with:with:with:with: to construct the argument
vector (or of course the convenient brace construct).

One could further wonder why are there so many of these seg* things floating
> around...


Because sometimes things come in octets...

>
>
> Just my opinion though,
> Andres.
>
>
>
> On Mon, Mar 24, 2008 at 6:09 PM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
>
> >
> >
> > On Sat, Mar 22, 2008 at 1:44 PM, Andres Valloud <
> > andres.valloud at gmail.com> wrote:
> >
> > > I think something that is being left unaddressed is whether using
> > > literal arrays that allow code expressions (e.g.: the brace syntax in
> > > Squeak) is a good practice or not.  In my experience, I have not felt the
> > > need for such things, but maybe I have not been exposed to particular
> > > circumstances in which they become useful.  Does anybody have some slam dunk
> > > examples that can be shared so that we can evaluate this better?
> >
> >
> > Just open any recent Squeak image and broseer senders of #braceArray,
> > e.g. the last line of
> > Bezier2Segment>>makeEllipseSegments: aRectangle in Squeak V3.9 reads
> >
> >     ^{seg1a. seg1b. seg2a. seg2b. seg3a. seg3b. seg4a. seg4b}
> >
> > instead of
> >     ^(Array with: seg1a with: seg1b with: seg2a with: seg2b),
> >       (Array with: seg3a with: seg3b with: seg4a with: seg4b)
> >
> > BTW, the first example tat comes up in my image contains:
> >     {'zip'.'sar'.'pr'. 'mcz'. '*'} includes: suffix
> > which is better written as
> >     #('zip' 'sar' 'pr' 'mcz' '*') includes: suffix
> > so one can argue that it can be confusing for some to have two
> > apparently similar constructs.  But in my experience {} carries its weight
> > (and there's no doubt that #() does).
> >
> >
> > >
> > > Andres.
> > >
> > > On Tue, Mar 18, 2008 at 9:57 AM, Eliot Miranda <
> > > eliot.miranda at gmail.com> wrote:
> > >
> > > > On Mon, Mar 17, 2008 at 2:11 PM, Craig Latta <craig at netjam.org>
> > > > wrote:
> > > >
> > > > >
> > > > >  > Defining new language elements is hard.  The worst that could
> > > > > happen
> > > > >  > to this project, is to have extremely long threads with no
> > > > > conclusion
> > > > >  > as on the Squeak list.
> > > > >
> > > > >      Indeed, although for what it's worth there's no lingering
> > > > > debate
> > > > > there on this particular issue[1]. ;)
> > > > >
> > > > >
> > > > > -C
> > > > >
> > > > > [1]
> > > > >
> > > > >      Namely, the short form of...
> > > > >
> > > > >      Array with: #foo with: #bar
> > > > >
> > > > > is...
> > > > >
> > > > >      #(foo bar)
> > > > >
> > > > > as in Smalltalk-80, and the short form of...
> > > > >
> > > > >      Array with: #foo with: true
> > > > >
> > > > > is...
> > > > >
> > > > >      {#foo. true}
> > > >
> > > >
> > > > Well, in Squeak 3.9 I get
> > > >
> > > > Welcome to the finale version of 3.9 of 7 of November 2006
> > > > #(nil true false foo) collect: [:ea| ea class] {UndefinedObject .
> > > > True . False . ByteSymbol}
> > > > #(nil true false foo) printString '#(nil true false #foo)'
> > > >
> > > >      But I suspect the appropriate standard use of curly brackets
> > > > > across multiple dialects is a whole other morass. :)
> > > >
> > > >
> > > > Having been living with Squeak for a while now I really, really like
> > > > the curly brace syntax.  I also note that it doesn't conflict with
> > > > e.g. VisualWorks use of #{name} for binding references.  So I have a
> > > > strong personal preference for it, but that's just personal.
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > ANSI-Smalltalk mailing list
> > > > ANSI-Smalltalk at lists.openskills.org
> > > > http://lists.openskills.org/cgi-bin/mailman/listinfo/ansi-smalltalk
> > > >
> > > >
> > >
> > > _______________________________________________
> > > ANSI-Smalltalk mailing list
> > > ANSI-Smalltalk at lists.openskills.org
> > > http://lists.openskills.org/cgi-bin/mailman/listinfo/ansi-smalltalk
> > >
> > >
> >
> > _______________________________________________
> > ANSI-Smalltalk mailing list
> > ANSI-Smalltalk at lists.openskills.org
> > http://lists.openskills.org/cgi-bin/mailman/listinfo/ansi-smalltalk
> >
> >
>
> _______________________________________________
> ANSI-Smalltalk mailing list
> ANSI-Smalltalk at lists.openskills.org
> http://lists.openskills.org/cgi-bin/mailman/listinfo/ansi-smalltalk
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openskills.org/pipermail/ansi-smalltalk/attachments/20080324/6b7665bf/attachment.html