[Squeakfoundation]An architecture for sustainable Squeaking

Henrik Gedenryd squeakfoundation@lists.squeakfoundation.org
Mon, 04 Jun 2001 20:55:44 +0200

Stephen Pair wrote:

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

OK, the special case I meant was when two different namespaces define
different methods for the same selector in the same class. That has to be at
least a little bit rare...

> Your concept of method namespaces is a bit off here.  The compiler does not
> instantiate anything...it only resolves names.

Correct me if I'm wrong, but I insist (with moderate certainty) that when
the source code contains a string literal (like 'bla bla') the compiler
creates a string literal that is stored within the CompiledMethod. And this
is done by code in the compiler.

> 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 ;)).
> ... BankAccount ...

Yah, now you are really talking about perspectives and that is kind of my
playground. If you have perspectives (which in this context in effect yield
multiple method dictionaries for the same class/instance) then you won't
need to hack this into the name spaces. You can do it cleanly. In fact you
can even disclose different slots (inst vars) in an object to different
perspectives, and it's fully natural to do so. Not a hack or a heresy at

In fact, single inheritance is really weak in a truly modular context. I
think many of the complications needed to support modularity go away with a
more powerful reflective paradigm/single-inheritance substitute. (I guess
this was a plug for my perspectives system, but I'm not sure. I see this as
a very long-term campaign anyway.)