From: Matthew Harris <shugotenshi@...>
Date: 2006-06-16T21:56:02+09:00
Subject: Re: Why the lack of mixing-in support for Class methods?

Heh, soon we'll end up adding other __*__ methods for the sake of it.

I don't see this as a benefit, and I've never really got down and
said, "Gee, I wish this method wasn't overridable!", and if I have, it
would have been for `send' which was easily remedied with `__send__'.

Also, for #object_id, there's already a #__id__.

On 6/16/06, Austin Ziegler <halostatue@gmail.com> 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.
>
> -austin
> --
> Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
>               * austin@halostatue.ca * http://www.halostatue.ca/feed/
>               * austin@zieglers.ca
>
>


-- 
Matt