From: Yukihiro Matsumoto <matz@...>
Date: 2006-07-07T22:22:22+09:00
Subject: Re: About 1.9 #__method__ feature.

Hi,

In message "Re: About 1.9 #__method__ feature."
    on Fri, 7 Jul 2006 21:30:03 +0900, dblack@wobblini.net writes:

|> But we already have module_function, which has never been complained
|> for more than 10 years.  I think it's OK to meet small confusion for
|> the first timers, if we can use the name with right mnemonic for the
|> functionality.  Probably the reason behind the funcall is my Lisp
|> background.
|
|I'm not a first timer though, and I find it confusing :-)  You're
|right about module_function, but it also (in my experience) doesn't
|get used much.

I think you're still a first timer to the term "funcall" in Ruby. ;-)
Anyway, my point is whether funcall etc. would work as good mnemonic
or not, _after_ users get used to them.

|The functionality we're talking about, as I understand it, is: send a
|message to an object, with the stipulation that the object treat the
|message indifferently with respect to the access level of the method
|(if any) that corresponds to the message.

Right, if I understand the work stipulation correctly.

|To me, that leads to things like send! or absolute_send or inner_send
|or instance_send (which I think Sean O'Halpin just suggested).  It's
|still basically a "send" operation.
|
|The part I don't understand is why the inclusion of private methods
|suddenly makes it something other than a "send" -- why it requires a
|(basically) new concept, the concept of objects having "functions" and
|responding directly to "call" requests.

"send" and "funcall" are both taken from lisp function names; "send"
invokes a method; "funcall" invokes a function.  In Ruby, "send"
invokes a method; "funcall" invokes a method in functional style.
They are short names for mnemonic.  There should be official, longer
orthogonal, and exact names for the functionality.  I proposed
"invoke_method" and "invoke_functional_method", but they are not final
decision.

							matz.