From: Stephen Pair <spair@...>
Date: 2001-11-28T00:08:48+09:00
Subject: [ruby-talk:26667] Re: Selector Namespaces: A Standard Feature for Smalltalk?

David,

I'm curious what (if any) changes would be required in the normal method
lookup algorithm in the VM?  I mocked up a solution to this in Squeak a
while back where I added a new class called "Selector" with two instance
variables (symbol & module).  When compiling methods in a module, instances
of Selector would be created for the messages (instead of instances of
Symbol).  Each module had its own Selector table (akin to the global Symbol
table).

To complete the experiment, I overrode #doesNotUnderstand: such that when a
Selector is encountered that was not understood, message lookup would
continue by locating another instance of Selector in a visible module, or by
falling back on the Symbol itself.  If none of these were understood by the
receiver, then the exception would be raised.  Overriding
#doesNotUnderstand: simulates the enhanced message lookup scheme that I
would put into the VM providing the experiment proved worthy.

There are of course several optimizations that could be made on this scheme.
The experiment worked very well.  With a little tweaking of some assumptions
that method dictionary keys were Symbols, the browsers handled it quite
nicely.  For example, I could (in a module) override
OrderedCollection>>#add: and break it without taking down the system.  My
module would happily invoke the broken version of #add:, while the rest of
the system continued to use the correct version of the method.  Also, from
this experience I could envision a system that was no more difficult to use
for novices than the current system (some objections to selector namespaces
that I've heard are that it would make the system too difficult to
understand).

So, again, my question...is it necessary to modify the message lookup
algorithm for your solution?  If not, could you shed some light on how you
avoided it?  If so, could you describe the enhanced algorithm?

Thanks,
Stephen