From: Brian Candler <B.Candler@...>
Date: 2003-05-06T17:49:43+09:00
Subject: Re: Variable/Method ambiguity

On Tue, May 06, 2003 at 09:49:44AM +0900, Gennady wrote:
> class Test
>   def name=(name)
>     puts "Called 'name=' ..."
>   end
>   def test
>     name = "aaa"
>   end
> end
> 
> Test.new.test
> 
> I would expect to see "Called 'name=' ...", as Ruby can realize here that method "name=" is available and call it. However, nothing is printed, meaning that an assignment to local variable "name" took place.
> 
> Is it only me who thinks that such behaviour is inconsistent?

I don't. I think you want Ruby to be 'clever' in examining the object to
work out whether a method exists. However the decision "is foo a local
variable or a method" is currently made at compile time, based on whether an
assignment to 'foo' has been seen previously in the method:

   def foo
     1
   end
   def test
     3. times do
       p foo    #>> 1  (the method)
       foo = 2
       p foo    #>> 2  (the variable)
     end
   end
   test

prints 1 2 1 2 1 2.

If this were to be made dynamic, then Ruby could not even code efficiently
"foo = foo + 1", because it wouldn't be known until runtime whether 'foo'
and 'foo=' were methods or local variables.

Perhaps more importantly, the behaviour of the code could also change
catastrophically if someone accidentally introduced a method into an object
which happened to have the same name as a local variable within one of its
methods. i.e. at the moment local variables are to a degree 'protected' from
this sort of outside interference.

It's all down to Ruby's decision to try and make things just work without
declarations. You could always introduce declarations for local variables,
or disambiguate them with a prefix:

     $foo = $foo + 1

but then Ruby would start turning into Perl...

Cheers,

Brian.