I think this is an idea worth experimentation. My first impression is that it would create more problems than it solves. If you pass any symbols from the code in one module to the code in another module, then use them as keys in identity dictionaries, you're going to get some un-expected results. And, for the novice, they'll be very difficult to comprehend (and thus debug). You also will not avoid having to re-do the development tools (imagine seeing two methods of the same name in the browser...which module does it belong to? how do I compile a new method for a specific module?).
I think the changes to implement this scheme would be no less difficult than the changes to implement it via enhancing the message look up and the method dictionaries. It may work, but it's a little more obscure IMO. If you've ever looked at the method lookup code, it's very straightforward.
The tricky thing is not really the mechanism itself, but making it simple to comprehend. The simple examples that have been discussed so far are...simple. What happens in the case that your module imports another module that overrides a method? Does your module use the overridden method, or the original one? What if you import two modules that override the same method? Which one do you use? Do you allow a way to explicitly prefer one over the other? Do you go by the order the modules were imported? What kind of complexity will this add to the method dictionary (now not really a dictionary but a more complex animal). You're really adding a new dimension to the method lookup scheme.
We could probably come up with a simple rule (such as breadth first, import order), and allow some mechanism to override the default lookup sequence (kind of like "super" allows us to override the default lookup scheme)...but again, whatever it is, it needs to be simple for 99% of the cases.
How would a symbol based approach solve this problem? Would it choose the symbol defined by one of it's imported modules?
It's difficult...it's been discussed for years...but it would be a big step on the trail to modularity and it would help put Squeak way ahead of other languages in this regard.
- Stephen
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
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation