From: Robert Klemme <bob.news@...>
Date: 2005-05-21T01:40:15+09:00
Subject: Re: syntax sugar: treating an object like a method

David A. Black wrote:
> 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 :-)

Yes I think so.  We saw this some days ago.

>> 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.

Probably.

Kind regards

    robert