modularity

Colin Putney cputney at wiresong.ca
Thu May 25 13:48:39 UTC 2006


On May 25, 2006, at 1:08 AM, Craig Latta wrote:

> 	The next version of Spoon has a subclass of Symbol, called  
> Selector. (I use a new Selector class for this so as not to disturb  
> traditional notions of Symbol identity.) The Selector class  
> implements multiple selector tables (similar in concept to a normal  
> symbol table). An author can specify via the tools that a method's  
> selector is not identical to any existing selector, and so should  
> be in a new table.
>
> 	When an author attempts to compile method source that uses a  
> selector that appears in multiple selector tables, the system asks  
> for disambiguation (e.g., by presenting the lead comment from the  
> corresponding method sources). The number of selector tables the  
> system maintains at any given moment is equal to the number of  
> meanings held by the most-overloaded method signature in the  
> system, and the system does reclamation as necessary (via weak  
> references). Method dictionaries use Selectors as keys, instead of  
> Symbols.
>
> 	Again, since behavior is transferred from one system to another  
> without relying solely on source code, this scheme is feasible.
>
> 	I'm not sure how much this feature would actually get used,  
> though. At this point it's more of a marketing-checklist thing. :)

Heh, yeah. Symbols are explicitly designed so that name and identity  
are *not* distinct.

One more question, though. How does Spoon maintain Selector identity  
across object memories? When a method is transferred from one object  
memory to another, how are the selectors in its literal frame  
interned when it arrives? I don't imagine the selectors have  
UUIDs.... perhaps the selector tables do?

Thanks,

Colin



More information about the Squeak-dev mailing list