From: "David A. Black" <dblack@...>
Date: 2005-05-20T22:44:23+09:00
Subject: Re: syntax sugar: treating an object like a method

Hi --

On Fri, 20 May 2005, Christian Neukirchen wrote:

> Eric Mahurin <eric_mahurin@yahoo.com> writes:
>
>> I was thinking that the local var vs. method preference would
>> remain the same to not break old code.  In the above example,
>> if you set:
>>
>> f = "hello world"
>>
>> In 1.8.2 f() would call the method f and now 1.9 will try to
>> call the object "hello world" (regardless of whether method f
>> exists).
>
> Oh, now that is bad.  The Ruby 1.9 I have around doesn't implement
> that yet, so I couldn't try.

From CVS today:

   irb(main):001:0> s = "hi"
   => "hi"
   irb(main):002:0> def s; "hello"; end
   => nil
   irb(main):003:0> s
   => "hi"
   irb(main):004:0> s()
   NoMethodError: undefined method `call' for "hi":String
         from (irb):4

I'm hoping it's just a temporary experiment :-)

> IMO, it should only call *when it responds_to?(:call)*, else give
> perference to the methods.

I agree.  I really don't like this:

   irb(main):003:0> p = "hi"
   => "hi"
   irb(main):004:0> [1,2,3].each {|n| p n }
   NoMethodError: undefined method `call' for "hi":String

I'm actually not a big fan of () even for #call-able objects.
(Sending the message "call" seems perfectly adequate to me, and I
really dislike the thought of more punctuation.)  But even if we get
that, I don't think it should go this far.  I realize that one could
say: just don't use the same names for methods and local variables.
But that seems very fragile.


David

-- 
David A. Black
dblack@wobblini.net