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
|