[Squeakfoundation]An architecture for sustainable Squeaking

[Jesse Welton]

Henrik Gedenryd wrote:
> 
> Well, this is essentially the problem addressed by allowing separate modules
> use the same selector for different methods. If you have that ability then
> there's no problem I guess.
> 
> We'll probably need to allow it, but I don't realistically believe this
> dual-methods thing will be among the first things we choose to spend time
> on. It's really a quite rare special case. I think we might classify it as
> allowed but preferrably avoided practice (cf. adding methods to Object). The
> "further in" toward the core, the more we'd try to avoid it unless
> warranted.
> 
> But I though about this example, in code inside a module:
> 
> 'bla bla' selectorDefinedTwice
> 
> Here, the Compiler creates a String. Are present implementations that allow
> this smart enough to instantiate a String as it is known in the creating
> namespace, with the right method defined?

I haven't followed the namespace issues too closely, so I have a
question here: Do you mean that in each namespace there is a different
String class object, with a different method dictionary?  In that
case, how would a String created in one namespace work within another?
It seems like it would be complicated to allow methods in one module
perform lookups in a different namespace than those in another module,
while retaining interoperability of the data.

In many ways, I think it would be simpler to ensure that the symbol
#selectorDefinedTwice defined in module Foo is a different object from
the symbol #selectorDefinedTwice defined in module Bar.  (That is,
they have the same string representation, but different identities.)
That would mean that classes could use flat method dictionaries,
shared between all namespaces.  It would be implemented by having a
separate symbol table for each namespace, arranged heirarchically.

When compiled, your method (in Foo) calling

 'bla bla' selectorDefinedTwice

would contain a reference to the symbol #selectorDefinedTwice found in
Foo's symbol table, rather than Bar's symbol table.  Any way your
method was called (including callback initiated from another module's
code), it would automatically call the right selectorDefinedTwice
method, without any change to the method lookup semantics.

Or is this crazy, for some reason I don't yet appreciate?

-Jesse