[Squeakfoundation]An architecture for sustainable Squeaking

[Stephen Pair]

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