Squeak (ST80) syntax

David N. Smith (IBM) dnsmith at watson.ibm.com
Thu Feb 17 20:52:11 UTC 2000


At 19:37 -0800 2/15/2000, Dan Ingalls wrote:
>Leandro (and Andres) -
>
>>    It's also a brainstorming kind of thing where outside
>>    ideas can be particularly useful.
>>
>>My 2 cents:
>>
>>In MathMorphs we've found contradictory the inclusion of a
>>starting 'self' when "writing on air". The same holds in
>>inspectors. If you are inspecting an Ellipse or writing it
>>on air, and you want to ask the Ellipse its position, then
>>there is no reason to write 'self position' when 'position'
>>alone describes the intention better.
>>
>>Sometimes, the use of 'self' goes against the illusion
>>created by Morphic, where one enjoys the direct manipulation
>>of objects. If I have an Ellipse at hand, I want to say it
>>'position', and not 'self position'.
>
>Yes.  We refer to this as "implicit self".  Alan is the strongest proponent of this appraoch in our group, actually, and SELF works this way as well.  We seriously considered this also back in ST-74 (!).  The two things that have prevented enthusiastic adoption of this approach are...
>
>	1.  As you say, "sometimes".  What about the other times?
>	Do you want to have "self" there sometimes and not others?
>	Is that making it easier to learn?
>
>	2.  What about messages to other objects?  there you always
>	state the receiver.  Do different rules apply in the two cases?
>	Is that making it easier to learn?

Doesn't 'implicit self' imply a common name space for methods and instance variables so that referencing the variable 'velocity' cannot be confused with 'self velocity'?

Does 'implicit self' provide any real gain in expressive power? If so, how does it change the Smalltalk model we all have become accustomed to?

I'm certainly not opposed to change, but I'd like to see something wonderful come out of it, some new expressive power, or some significant simplification.

Dave
_______________________________
David N. Smith
IBM T J Watson Research Center
Hawthorne, NY
_______________________________
Any opinions or recommendations
herein are those of the author  
and not of his employer.





More information about the Squeak-dev mailing list