From: transfire@...
Date: 2006-06-14T11:53:32+09:00
Subject: Re: Why the lack of mixing-in support for Class methods?


Yukihiro Matsumoto wrote:

> That makes modules too "special".  Every object has its own "singleton
> class" (aka eigenclass) no matter what class it belongs to, under the
> current implementation.  After your proposal, modules should be
> treated specially not to have ordinary singleton classes.  I know its
> purpose (to allow injecting a module's singleton methods using
> #include), but I am not sure if it's worth making object model
> complex.

I see your point. This solution is kind of drastic in that respect.
Although I sort of liked the symmetry of a module being a module from
"head-to-toe" ;) And it's knid of too bad too, b/c this solution
limited the capability just to module's class-level, where it's needed
and no where else. Other solutions tend to be much broader and/or
hackish.

> It seems Daniel's _API_ is good enough.  What's wrong with the idea?
> Except for implementation issues, of course.

Well, that's what I've been using already. In fact, as far as I can
tell the Facets' implementation is the most complete around (not to say
it can't be improved). But even so, it is hackish, inefficient, and
fragile, and that really can;t be hellped because of the naturr of
implementing it. And its' made worse in that the techinque is without
standard, so nayone can run roughshod right over it. These are the
reasons why I've asked you directly about the issue. I'm essentially at
my wits end with it. I've spent more hours on this one problem than I
care to admit.

This evening is sadly no exception. I attempted another implementation,
which I think has a better overall interface (not as good as just being
able to include the singleton, but...)

  module M
    def meta.x
       self
     end
  end

  class X
    meta_include M
  end

  X.x #=> X

Alas, an implementation of this appears to be impossible. Again those
singleton methods are just out of reach and it is frustrating to no
end.

T.