Killer Squeak App?

Stephen Pair spair at advantive.com
Wed Aug 22 22:10:43 UTC 2001


Henrik Gedenryd wrot:

> Stefan Matthias Aust wrote:
> 
> > In the last squeak, I changed my mind an nowadays, Self has 
> not enough 
> > syntax for my taste. You really have to get used to all 
> that (| .. |) 
> > object declarations ( ) method declarations, implicit self 
> sends and 
> > the fact that even local variables doesn't exist.
> 
> I'd like to hear your opinion: do you think it is an 
> advantage to allow receiver self to be implicit? I have 
> started to think that this breaks the simple principle of 
> always having the "receiver message" pattern and thereby 
> causes more irregularity than advantages. But I'd like to 
> hear others' opinion on this, I don't have a strong opinion 
> yet. Jecel and John Maloney might have something wise to say 
> about this as well?

I have questions about the notion of name resolution being tied in with
message lookup.  My gut tells me that these shouldn't be so intertwined.
If you really want name resolution via a message send, then do "self
orderedCollection" otherwise just use "OrderedCollection" and allow the
compiler to resolve it.  You could take it a step further and have the
compiler ask the mirror to resolve the name (in which case, you can
resolve names however you want)...this is analagous to the current
implementation where the compiler looks to the class for help in
resolving names.

Therefore, if you want to have flexibility in name resolution, dropping
the "self" keyword would make that a challenge.

Regarding delegation in Squeak and compiling methods, there are really
three issues to resolve:

- a syntax for a directed resend (the current super syntax will
accomplish an undirected resend).  I had thought about using a *
following the variable name (i.e. "parent* doSomething"))...I don't
particularly care for the Self syntax here, however it does allow for
other types of messaging (i.e. "anObject async.doSomething).  I think
the Self syntax is "parent resend.doSomething".

- Allowing for overriding of slot getters and setters:  For this, I was
thinking that the using the normal Smalltalk instVar access and
assignment operators would be fine (the compiler would turn these into
bytecodes appropriate for prototypes).  In this way, you could also do
direct instvar access in other methods (but obviously this impacts the
re-usability).

- Saving of method source: I thought a simple solution to this would be
to have the ProtoBehavior hold onto the source strings, and allow one to
instruct it to not to keep method source if that isn't desired.  (it
would also be a simple matter to write something that could install a
constructor on an existing method in the class system).  On the other
hand, we could go for something more advanced that would allow source to
be written into the changes file, we could accomplish that by allowing
prototypes to be owned by some existing class, given a name, and kept in
some dictionary off the class.  OTOH if we had a nice virtual object
memory system, we wouldn't need a source or changes file in the first
place, and storing source in the virtual image wouldn't be an issue. ;)

- Stephen





More information about the Squeak-dev mailing list