cstb wrote:

> So the trace is
> (self transformer) selector
> --> (self class transformer) selector
> --> ActualReceiver selector
>

What I'm proposing is to always access a global
or class (for instance NeededClass below)
with something like:

self NeededClass
--> (self whichClassToUse) NeededClass "POSSIBLY"
--> (self class whichClassToUse) NeededClass "POSSIBLY"
--> ActualReceiver NeededClass "POSSIBLY"

The point being that the most important / valuable
step is the first one. I don't go into detail
of what *should* happen inside 'self NeededClass'.

Using 'whichClassToUse' inside it may indeed
the best solution, but I allow the situation and
circumstance affect that decision. In effect I
encapsulate this decision inside my (i.e. self's)
method #NeededClass.


In Smalltalk, the SystemDictionary 'Smalltalk' is the
'holder of globals'. In fact the compiler gets the
classes from it - but with no regards to encapsulation.
Therefore in many cases I've written:

self NeededClass
--> self Smalltalk NeededClass

The above I think follows your pattern closely:
Delegate to an object responsible for knowing
the thing asked for, but do the delegation by
accessing the delegate via a further message-send.

Since 'Smalltalk' (The SystemDictionary) above is
accessed via a method, it is easy to come up with
the idea that each 'self' may in fact have their
own SystemDictionary. Then it becomes only natural
to make the small step of calling such objects
'namespaces' instead:

self NeededClass
--> self namespace NeededClass


But as I said I find such indirection often *more
than enough*, and would rather refactor my code
to that form only when needed.

Why? Looking at the last example, I still don't know
which *actual* class gets returned, and figuring that
out takes an extra level of effort.

There's a fine balance between *forces* of minimizing
dependencies, and maximizing readability. How to balance
these forces naturally depends on the circumstances.

- Panu Viljamaa