Re: Issue 2190 in pharo: at:put: return the argument

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Issue 2190 in pharo: at:put: return the argument

pharo
Updates:
        Labels: -Milestone-1.3

Comment #5 on issue 2190 by [hidden email]: at:put: return the  
argument
http://code.google.com/p/pharo/issues/detail?id=2190

(No comment was entered for this change.)


Reply | Threaded
Open this post in threaded view
|

Re: Issue 2190 in pharo: at:put: return the argument

pharo

Comment #6 on issue 2190 by [hidden email]: at:put: return the  
argument
http://code.google.com/p/pharo/issues/detail?id=2190

Note that bitAt:put: is ANSI, and that it won't modify the receiver but  
return a copy.
We cannot change it, no way.

I would say let's do it for #at:put: then discuss about the other ones in  
another issue if you want.
I advocate consistency because of least surprising effect...

The first time this was really usefull to me was for translating this DSL:
   d := a[i] := b[j] := c := 3;
into:
   d := a at: i put: (b at: j put: (c := 3)).
This also provides a Rationale for original st-80 design.

Of course, you then have to explain #yourself to noobs with such  
implementation, but that's not that difficult to explain, and i find it  
worth.



Reply | Threaded
Open this post in threaded view
|

Re: Issue 2190 in pharo: at:put: return the argument

pharo

Comment #7 on issue 2190 by [hidden email]: at:put: return the argument
http://code.google.com/p/pharo/issues/detail?id=2190

Agreed, ANSI-compatability should stay.
Funny name they ended up with though.
Would be nice to get around to annotating them with tags some time in the  
future so we know not to change them :)

Like I said, all those are already in, the only question is if it should  
consistenly raise an error if unable to add as well, or if returning some  
value indicating failure should be allowed. (Like XTableForUnicodeFont)