modularity

Craig Latta craig at netjam.org
Thu May 25 05:08:49 UTC 2006


Hi Colin--

 > > Being able to associate multiple methods with the same method
 > > signature avoids another major source of collisions (and places
 > > similar demands on the tools that unconstrained class names do).
 >
 > Oh? That's an aspect of Spoon I was unaware of. Can you point me
 > toward a more thorough description?

	Sadly, no, not yet; I'll just have to write one here. :)

	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. :)


	thanks,

-C

-- 
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]



More information about the Spoon mailing list