From: transfire@...
Date: 2006-06-16T16:13:35+09:00
Subject: Re: Why the lack of mixing-in support for Class methods?


Austin Ziegler wrote:
> On 6/15/06, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
> > |Thankfully all the important ones (except #dup
> > |and #clone) start with either '__' or 'instance_' (eg. __send__). But
> > |#funcall will add another exception. It would be nicer to see a
> > |consistant pattern in the naming of these meta-methods.
> > Good point.  We will have __funcall__ as well.  Thank you.
>
> Should we have __dup__ and __clone__ and __class__ and __object_id__?
>
> I am already using #__send__ in preference to #send when I need the
> functionality, but it would be nice to know that for those methods we
> literally cannot get along without ... we have access to without
> rebind hacks.

I agree. And I did add __class__ in basic object, though I find it's
not so often needed b/c of 'X === x'.  Nonetheless it certainly seems
like one of the fundamentals. BTW, we have __id__ already, so I don't
think __object_id__ is needed.

I've also expiremented with two other methods, #__self__ (alias
#object) which is a Functor that binds subsequent calls to Object. Eg.
x.__self__.class will return the class of x even if x.class won't. I
took it a step further with #as / #__as__, in which one can specify
which ancestor to bind to instead of just Object.
x.__as__(Enumerble).each, for instance.

Food for thought.

T.