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