[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: syntax sugar: treating an object like a method

Eric Mahurin

5/19/2005 3:53:00 PM

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



3 Answers

Christian Neukirchen

5/20/2005 1:02:00 PM

0

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://chneuk...

dblack

5/20/2005 1:44:00 PM

0

Robert Klemme

5/20/2005 4:39:00 PM

0

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