[Squeakfoundation]An architecture for sustainable Squeaking

[Stephen Pair]

> 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.

Hmmm...I don't think this is a special case at all...you may be right about
it not being one of the first things implemented, but adding methods to
Object is done quite commonly (and by necessity).  Usually, adding a method
to Object is cleaner than trying to avoid doing so (see Andreas' argument in
favor of #is* methods over using #isKindOf:).  The real problem with doing
such is the fact that we don't have a solution for method namespaces.
Avoiding such method additions leads to code that is convoluted, difficult
to maintain, and generally not well written.

> 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? Because the Compiler's
> namespace,
> when the literal-compiling method is defined, would certainly not know of
> either of the two definitions.

Your concept of method namespaces is a bit off here.  The compiler does not
instantiate anything...it only resolves names.  When a String is
instantiated (in the case where there are two different implementations of
#selectorDefinedTwice), the same String class is used (unless you've defined
your own String class in your module), however the mechanism in which the
*selector* is resolved to a method is smart enough to choose the correct
method based on the context (module) in which the message was sent.

This is why I said that this would require deep modifications to the message
dispatch mechanism and to method dictionaries.  However, it's not
impossible, it probably needs to be prototyped in the image before expending
the effort to change the VM (which will ultimately be needed if a solution
that performs well is desired).  Also, such a change in the dispatch
mechanism of the VM may adversely affect the performance of Squeak overall,
but hopefully the impact can be made small enough that the trade off is well
worth it.

Also, there is a real life analogy that can be made.  When you are sent
messages from people in real life, you are likely to respond in different
ways depending on who is sending the message...you may even respond more or
less promptly depending on the sender (my wife gets a very high priority
response...most times ;)).

Finally, having such a mechanism in place may ultimately allow us to
reconcile the benefits of a Morphic all in one design vs. an MVC keep
everything separate.  With such a mechanism, a GUI module that depends on a
Morphic module could add Morphic methods to a BankAccount without affecting
(or intermixing) with the domain Behavior that the BankAccount domain module
creates.  (We may need to expand the scope to allow modules to add instance
variables in addition to methods however).  But, let's take it one step at a
time...there are likely to be a lot of people that label me a heretic based
on this final comment (due to the almost religious status that MVC has
achieved)...but I'd love to have a system where this sort of thing could be
experimented with.

- Stephen

P.S.  Dave Simmons was mentioned as an authority on this subject...does he
have any papers on web about this topic?