Hi --

On Mon, 21 Mar 2005, Navindra Umanee wrote:

> David A. Black <dblack / wobblini.net> wrote:
>> I'm not sure about the naturalness of it -- I'm more thinking about
>> the fact that () isn't a method, whereas x(), where x is an object
>> reference (rather than a method identifier), looks like you're calling
>> the method () on x.
>
> It isn't a method in 1.9?

No:

irb(main):006:0> {||}.methods.grep(/\(/)
=> []


> Well, maybe it will be made a method or at least a synonym/alias for
> call, although I guess that parsing-wise you might have to find a
> compromise.
>
> x() doesn't really look like a method any more than x[] does...

Actually there's a kind of double reasoning process involved here.
x[] is a method designed *not* to look like a method -- but it *is* a
method, can be redefined, etc.  Therefore, () attached to a variable,
while also not looking like a method, looks like it should be one of
those things that don't look like methods but actually are.  So it's
really within the framework of this kind of Ruby idiom that what I'm
saying applies.

That's why the overall naturalness or universality of () as a call-ish
thing isn't (for me()) the key thing.  I don't want lambdas to know
about () unless () is a method.  The best analogy is container
objects, which don't automatically know that they can be indexed with
[] but come to that point through the definition of the method #[].

(I offer the analogy for its explanatory power, not because it proves
that () "should" behave analogously -- though I think it should :-)


David

-- 
David A. Black
dblack / wobblini.net