About {} and its limits
stéphane ducasse
ducasse at iam.unibe.ch
Tue Feb 8 13:53:33 UTC 2005
On 8 févr. 05, at 14:11, Bert Freudenberg wrote:
> Am 08.02.2005 um 12:00 schrieb stéphane ducasse:
>
>> yes.
>> this is what I thought after.
>> But this was an interesting example of the limit of syntactic sugar.
>
> Why would you think so? #printString is supposed to deliver a readable
> representation, not an executable one, that's what #storeString is
> for. It's not a limitation of {} at all.
No because for some objects: true, false, character, symbol, string,
1,2 the store string representation is equals to the input form and {}
breaks this rule. Array storeOn has to be written Array new: ...add:
because an array can only contain literals but {} is different
Imagine that {} would create an instance of DynamicallyCreatedArray A
subclass of Array, then collect by using species would return object of
this class and with an adequate printOn:
we could close the loops: ie using a textual representation understood
by the compiler to manipulate the object. No need to know that we
should have a special storeOn: method on array.
Therefore with a simple fix {} would be much better integrated than it
is now.
I think that this is related with my lisp background
as in lisp
1 evaluates in 1
true evaluates in true
'klk;lk' evaluates to 'klk;lk'
We could have { 10 at 10 . 20 at 20 } prints as { 10 at 10 . 20 at 20 }
and #(10 @ 10 ) prints as #(10 @ 10 )
This way the programmer does not have to think that {} is a shortcut or
a hack
and know ok {} is just a textual input for the same objects.
So why this solution is worse than the current one?
Stef
More information about the Squeak-dev
mailing list
|