[ENH] Symbol Spaces

Allen Wirfs-Brock Allen_Wirfs-Brock at Instantiations.com
Fri May 10 19:17:23 UTC 2002


At 02:06 PM 5/10/2002 -0400, Stephen Pair wrote:
>It's hard to describe this stuff in text.

This may or may not help...One way to describe what Stephen has done is to 
create a distinction between "selectors values"  and "selector names" that 
is analogous to the distinction between actual variables and variable 
names. Just as a single variable name may be bound to multiple distinct 
variables at different times and in different parts of a program so can a 
single selector name be bound to multiple distinct selector values in 
different parts of the program.

In Classic Smalltalk-80, selector names and selectors  value are the same 
thing -- they can not be separated. Stephen's work splits the two concepts. 
Selector values are the things that actually identify methods and drive 
method resolution. Selector names are just the identifiers that are used 
when writing a method to refer to a selector value. This binding between a 
selector name and a selector value may be context sensitive.

For those of you who aren't already familiar with it, the second half of my 
"Smalltalk Subsystems" proposal 
(http://www.smalltalksystems.com/publications/subsys.pdf) describes various 
interesting things that can be done once you make a distinction between 
selector values and selector names.  (starts on page 6 with the section 
titled "Message Selector Conflicts".

My major reservation about this approach has always been a concern about 
understandability and usability. While the distinction between a name and 
its binding as normal and obvious for compiler writers like me it's not so 
clear that the distinction is all that obvious to many Smalltalk 
programmers.  Symbol==method selector==method lookup key is a nice concrete 
concept that is easy to explain. Adding the extra level of indirection 
probably add an "order of magnitude" to the conceptual complexity of this 
part of the language.

Allen Wirfs-Brock










More information about the Squeak-dev mailing list