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
spoon@lists.squeakfoundation.org