On Oct 6, 4:20=A0pm, "Austin Ziegler" <halosta... / gmail.com> wrote:
> On Mon, Oct 6, 2008 at 3:34 PM, Trans <transf... / gmail.com> wrote:
> > On Oct 6, 2:11 pm, _why <w... / ruby-lang.org> wrote:
> >> While investigating Guy Decoux's old messages, I've recently
> >> discovered a way to do exactly this. =A0It involves inserting a mixin
> >> into the inheritance chain and then enabling and disabling it as
> >> needed.
>
> >> <http://hackety.org/2008/10/06/mixingOurWayOutOfInstanceEval.html>
>
> > Jimmy Crickets! That code is so straight forward. Er... Why isn't this
> > core Ruby?
>
> What I'm wondering is if this might be a way to do selector namespaces
> that everyone has been asking for...

The idea of selector namespaces being that an extension applies
according to where (eg. the nesting) that an *invocation* of a method
takes place? That being the case, 'mixin/unmix' could be used, but
wouldn't the constant extending and unextending of objects be a huge
performance drain? Every method would effectively have to be prepended
with a procedure to check to see if the current nesting has changed
since the last invocation, and if so change the selected extensions
accordingly. Maybe the overhead isn't as great as I fret, but
certainly this could be happening thousands of times a second.

The only effective way I see for implementing selector namespaces is
via some sort of routing. Instead of tying a module into the class
hierarchy with direct reference pointers via a Proxy, it would need to
go through a Router that directed it to the appropriate extension
module according to the current nesting.

For example, instead of swapping the Proxy in and out, ocillating
between say:

  AClass --> ASuperClass

then

  AClass --> Proxy --> ASuperClass
              |
              '--> ModuleA

then

  AClass --> Proxy --> ASuperClass
              |
              '--> ModuleB

Rather we need:

  AClass --> Router --> ASuperClass
              |  |
              |  '--> ModuleA
              |
              '--> ModuleB

However, though I never quite understood why, but whatever causes the
well known Module Inclusion Problem, will likely be an issue with
something like this too.

T.