[ruby-core:34630] Re: [Ruby 1.9-Feature#4288][Open] Allow invoking arbitrary method names with foo."something" syntax

On Jan 19, 2011, at 5:35 PM, Charles Oliver Nutter wrote:
> On Wed, Jan 19, 2011 at 2:58 PM, Gary Wright <[e-mail]> wrote:
>> Maybe I'm crazy, but could I suggest something a little more general?
>> 
>>   foo.{expression}(arg1)
>> 
>> to have the same semantics as
>> 
>>  foo.send(expression, arg1)
> 
> I don't want something that just resolves to doing "send" under the
> covers.

I probably wasn't clear. I also don't want syntactic sugar for #send
but instead a way to dynamically name a method without the extra step
of looking up the implementation of #send.

> I want this code:
> 
> foo."something"()
> 
> to parse identically to:
> 
> foo.something()
> 
> What I want is purely a syntax-level quoting mechanism for method invocation.

I was trying to expand on your idea a bit to produce a more
general approach that still addressed your use case:

  foo.{"something"}()

can still be optimized to the same parse tree as

  foo.something()

but it also admits the use of an arbitrary expression to generate
the name of the method to call.

>> Perhaps a syntactic approach to dynamic dispatch would enable more interesting optimizations since it would be clear that something 'interesting' was going on rather than just a generic method call to a magic method like Kernel#send.
> 
> If you mean that the above syntax would actually parse to those
> literal call names (rather than bouncing through send) then I have no
> objections. I feel like foo."something" is cleaner, though, and the {}
> immediately says "block" to me. If that was your intent...I think
> that's going a bit too far :)

I did suggest {} because it is used to denote code in both string interpolation and blocks.  I was simply building on that idea. As you suggested in your original posting there is an open question of whether string interpolation should be allowed in this context. My first thought would be that having a new syntactical construct that was based on double-quotes but that didn't allow for string interpolation was confusing and/or a missed opportunity.

Of course you could introduce a single quote construct that did not do string interpolation. In fact if you don't want string interpolation in this construct I would argue that single quotes make more sense.

  foo.'something'()

If you allow string interpolation then your proposal also introduces the use of {} to evaluate code:

  foo."prefix_#{ compute_method_name }"()

Once you admit that usage I don't think that my syntax is all that crazy.

BTW, I suspect that any of these ideas (single quotes, double quotes, or braces) is going to complicate the parser...

Gary Wright