From: Brian Candler <B.Candler@...>
Date: 2003-04-10T01:54:58+09:00
Subject: Re: Proc Question

On Thu, Apr 10, 2003 at 01:20:17AM +0900, Travis Whitton wrote:
> As I was coding this morning, a question occured to me. Why must proc objects
> have a call method? I'm sure that there's a good reason for this, but it seems
> like it would be more natural for proc objects to behave as regular methods
> do and avoid the .call() syntax.
> 
> I.e.,
> square = proc {|n| n * n}
> square(4) # => 16

square(4) currently is a method call, i.e. self.square(4), or
self.call(:square,4) for the long-hand version.

What you are proposing is that foo(x) should mean foo.call(x) if 'foo' is a
local variable in the current scope, or self.foo(x) if not.

Whilst this is feasible, I think there is already enough syntactic magic
based on whether a local variable exists or not; I personally wouldn't want
to see any more!

e.g.

     puts foo

uses the variable 'foo' if one exists with that name, or calls the method
'self.foo' if it doesn't. But

     foo = 3

is always an assignment to variable 'foo', not a call to method 'self.foo=(3)'

Regards,

Brian.