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

> If one decides to call #call magically (which I'm quite
> opposed to),
> local variables should have preferrence, I think.
> 
> 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.



		
Discover Yahoo! 
Find restaurants, movies, travel and more fun for the weekend. Check it out! 
http://discover.yahoo.com/weekend.html