From: Gary Wright <gwtmp01@...>
Date: 2011-01-20T07:09:00+09:00
Subject: [ruby-core:34621] Re: [Ruby 1.9-Feature#4288][Open] Allow invoking arbitrary method names with foo."something" syntax


On Jan 19, 2011, at 4:22 PM, Nikolai Weibull wrote:

> On Wed, Jan 19, 2011 at 21:58, Gary Wright <gwtmp01@mac.com> wrote:
> 
>> On Jan 18, 2011, at 12:51 AM, Charles Nutter wrote:
>>> For non-standard or arbitrary method names, it would be nice to have a way to invoke them directly that doesn't require the parser to be made more complex nor require an intermediate "send" call. Groovy does this by allowing the following form:
>>> 
>>> foo."asdf"()
> 
>>  foo.{some_variable}()
> 
>> I've always found the use of Kernel#send for dynamic method dispatch to be a bit awkward and would prefer something that was syntactically similar to static method dispatch rather than the current dependency on the 'magic' behavior of Kernel#send.
> 
> Could you explain how foo.{some_variable}() is less magic than
> foo.send(some_variable)?  I am currently of the opposite opinion.

By magic I mean "having semantics that aren't evident from the syntax".  Consider:

	hash.fetch(:foo)
	udpsocket.send("somedata", 0)
	someobject.send(method_name, "arg")
	another_object.__send__(method_name, "arg")

From a syntactic point of view these all look like standard method calls but two of them are actually dynamic method dispatches.  The parser (or programmer) can't see that though from the syntax alone.  The shift towards __send__ illustrates the tension associated with using methods to implement language features/semantics.  The problem is minimized by crafting a special namespace but that just serves to highlight the magic nature of the method.

My suggestion, or Charles' suggestion if you allow for string interpolation, makes the dynamic nature of the method call evident from the syntax. There is no hidden or magic semantics that you need to know about in order to understand the *language* semantics of the method call as the (proposed) syntax itself signals the semantics.

The use of a magic method also forces the runtime to do a slow method lookup for 'send' only to restart the process with a new name when it discovers that 'send' (or '__send__') hasn't been surreptitiously redefined.  Charles' can probably comment on that problem better than I though as I think it comes into play with other Ruby 'methods as language features' also (e.g. #eval).

Gary Wright