From: Christian Neukirchen <chneukirchen@...>
Date: 2005-05-20T22:01:49+09:00
Subject: Re: syntax sugar: treating an object like a method

Eric Mahurin <eric_mahurin@yahoo.com> writes:

> --- Christian Neukirchen <chneukirchen@gmail.com> wrote:
>> Eric Mahurin <eric_mahurin@yahoo.com> writes:
>> 
>> > And one more thing.  If someone has both a local variable f
>> and
>> > a method f, we have different behavior in 1.8.2 vs. 1.9:
>> >
>> > f = lambda {|*args|puts("lambda",*args)}
>> > def f(*args);puts("method",*args);end
>> > f(1,2,3)
>> >
>> > 1.8.2 calls the method and 1.9 calls the lambda.  This
>> seems
>> > bad.  So it looks like the priority between local variables
>> and
>> > methods has been reversed - 1.8.2 prefers methods and 1.9
>> > prefers local variables.  You can no longer use "()" to
>> > distinguish the two.  Maybe is does make sense because they
>> are
>> > in the same namespace and local usually overrides, but
>> people
>> > need to be aware.
>> 
>> Wasn't that just what you wanted?
>> Remember that Ruby 1.8 cannot call lambdas directly.
>
> 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.

IMO, it should only call *when it responds_to?(:call)*, else give
perference to the methods.  You can see, faking first-order functions
is harder than imagined. :-)

>> Finally, () only defines evaluation order/parameters, there
>> is no way
>> (and there shouldn't be, IMO) a method will behave
>> differently when
>> called with or without parentheses.
>
> I like the new priority better (local variables always win -
> regarless of parens), but it will cause just about any code
> that local variables and methods with the same name to break.

Since Ruby 2 is going to break lots of code anyway, this may not be a
severe problem.

I fear more that the Ruby core will get random and inconsistent
by adding features without a lot of thought.

-- 
Christian Neukirchen  <chneukirchen@gmail.com>  http://chneukirchen.org