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