From: transfire@...
Date: 2006-07-04T01:10:40+09:00
Subject: Re: About 1.9 #__method__ feature.


Yukihiro Matsumoto wrote:
> Hi,
>
> In message "Re: About 1.9 #__method__ feature."
>     on Mon, 3 Jul 2006 23:33:54 +0900, transfire@gmail.com writes:
>
> |I think the name  __method__ is probably a poor choice b/c "shadow
> |methods" (as I call them) do the same thing as their non-shadow forms.
> |Eg. #__send__ and #send, #__id__ and #id, etc. But #__method__ is an
> |exception since #method currently returns a Method object given the
> |name, not the name of the current context.
>
> It's not conjunction with __send__ etc. but with __FILE__ and
> __LINE__.  Besides that, I am no longer fond of __send__ and __id__,
> I'd rather like to remove them if it's possible.  Use invoke_method
> and object_id respectively instead.

I'd agree, but we need a better system to replace them --not a worse
system. Granted __xxx__ methods aren't pretty but at least they are
consistant and one knows what to expect. Now we are going to have to
recall, teach, fix broken programs, and generally take into account
even more methods like #invoke_method (what's that do different from
#send btw?) and #funcall.

I'm looking at this primarily from the point of view of BlankSlate. I
think that application really drives home how all this effects the
system. For example, recently a user tried to use an #eval in a
BasicObject (ie. BlankSlate) and it bombed (of course). So I ask myself
should there be a __eval__? One could ask this about lots of methods. I
also noticed that the problem is worse when there is a built-in
BasicObject like in Ruby 1.9 b/c then there is no way to get to those
methods at all! So I think maybe this is all the wrong approach. And
the only solution I can think of is separate namespaces for public vs.
private methods.

What is you take on this?

Thanks,
T.