On Fri, Oct 30, 2009 at 1:45 PM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

> 2009/10/30 Eliot Miranda <eliot.miranda at gmail.com>:
> >
> >
> > On Fri, Oct 30, 2009 at 12:55 PM, Andreas Raab <andreas.raab at gmx.de>
> wrote:
> >>
> >> Question: I've always wondered what this "isSelfEvaluating" stuff is
> good
> >> for. There are thirteen implementors and a single user in
> Array>>printOn:.
> >> Is there any *need* for Array>>printOn: to print a "self evaluating"
> >> expression? Why not just Array(element1, element2, ....) just like any
> other
> >> collection?
> >>
> >> We'd remove some 20 methods with no downside that I am aware of.
> >
> > Shouldn't the test be isLiteral instead of isSelfEvaluating? c.f.
> storeOn:
> > storeOnStream:.
> >
>
> Yes that's the default behaviour of Object>>isSelfEvaluating.
> But the 3.9 team wanted to extend this to a few other objects, like
> Point, Rectangle, ...
> The reason for this extension is the presence of brace notation.
>

Right.  So with braces one either prints arrays as literals or as braces.
 Whether an element of an array prints as self-evaluating is up to it right?
 e.g. I would prefer it if

    Array with: OrderedCollection new

prints as { OrderedCollection () } than #(OrderedCollection ()).  The first
is a syntax error but the second is completely ambiguous (i.e. evaluates to
 #(#OrderedCollection #())).

So I don't see the need to provide isSelfEvaluating.  isLiteral gives you
all that you need to avoid printing an Array as a literal when it isn't.
 And if you've drunk the braces kool aid (which I have, while studying my
agrippa) you're happy with Arrays printing themselves as brace constructs
naively even when the naive print produces non-code.


> Nicolas
>
> >>
> >> Cheers,
> >>  - Andreas
> >>
> >
> >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20091030/6ae0aff1/attachment.htm