Forum: Ruby Why does attr_accessor in module require 'self.'?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Brian H. (Guest)
on 2009-04-28 02:30
Hi there,

When a class mixes in a module containing 'attr_accessor :foo', it must
then use 'self.foo = ...' instead of simply 'foo = ...'.  While I prefer
'self.foo' for clarity's sake, I am stumped as to _why_ this is
required.  For example:

module A
  attr_accessor :a
end

class B
  include A

  def bar
    a = "bar"
  end

  def baz
    self.a = "baz"
  end
end

module A
  attr_accessor :a
end

class B
  include A

  def bar
    a = "bar"
  end

  def baz
    self.a = "baz"
  end
end

irb(main):050:0> b = B.new
=> #<B:0x2db69cc>
irb(main):051:0> b.bar
=> "bar"
irb(main):052:0> b.a
=> nil
irb(main):053:0> b.baz
=> "baz"
irb(main):054:0> b.a
=> "baz"

Does anyone know why this is?

Thanks!

Brian H.
John B. (Guest)
on 2009-04-28 02:40
(Received via mailing list)
Hi,

On Apr 27, 2009, at 3:30 PM, Brian H. wrote:
> When a class mixes in a module containing 'attr_accessor :foo', it
> must
> then use 'self.foo = ...' instead of simply 'foo = ...'.  While I
> prefer
> 'self.foo' for clarity's sake, I am stumped as to _why_ this is
> required.  [snip]

It's because Ruby automatically creates local variables upon
assignment. Given a class with a method "foo":

class C
   attr_accessor :a

   def foo
     a = 42 # this is a local variable assignment
     self.a = 42 # this is a call to the "a=" method
   end
end


~ j.
Joel VanderWerf (Guest)
on 2009-04-28 02:48
(Received via mailing list)
Brian H. wrote:
>
> end
In B#bar, ruby's parser sees "a = ..." and assumes that "a" is local
variable, rather than attempting to call #a= (the writer method). This
has the advantage that, since local variables always "shadow" methods of
the same name, you can write code with the confidence that you are not
invoking some method defined in the class (or somewhere up the ancestor
chain) that you hadn't noticed. For one thing, this makes it easier to
write code that knows as little as possible about its context, and hence
can be shared around by Module#include or even copy-n-paste.

It is, however, a disadvantage for DSL design, but that's another
story...
7stud -. (Guest)
on 2009-04-28 16:26
John B. wrote:
>
> It's because Ruby automatically creates local variables upon
> assignment. Given a class with a method "foo":
>

Can attr_accessor ever apply to variables that don't begin with @?
Ryan D. (Guest)
on 2009-04-28 23:14
(Received via mailing list)
On Apr 28, 2009, at 05:26 , 7stud -- wrote:

> John B. wrote:
>>
>> It's because Ruby automatically creates local variables upon
>> assignment. Given a class with a method "foo":
>>
>
> Can attr_accessor ever apply to variables that don't begin with @?

no, otherwise it'd be named something else.
7stud -. (Guest)
on 2009-04-29 01:35
Ryan D. wrote:
> On Apr 28, 2009, at 05:26 , 7stud -- wrote:
>
>> John B. wrote:
>>>
>>> It's because Ruby automatically creates local variables upon
>>> assignment. Given a class with a method "foo":
>>>
>>
>> Can attr_accessor ever apply to variables that don't begin with @?
>
> no, otherwise it'd be named something else.

Well, then what's all this talk about "the parser sees this, and the
parser does that".  The op never tries to access an instance variable in
the classs, so the fact that a call to attr_accessor is in the class is
irrelevant.  End of story.
7stud -. (Guest)
on 2009-04-29 02:14
7stud -- wrote:
> Ryan D. wrote:
>> On Apr 28, 2009, at 05:26 , 7stud -- wrote:
>>
>>> John B. wrote:
>>>>
>>>> It's because Ruby automatically creates local variables upon
>>>> assignment. Given a class with a method "foo":
>>>>
>>>
>>> Can attr_accessor ever apply to variables that don't begin with @?
>>
>> no, otherwise it'd be named something else.
>
> Well, then what's all this talk about "the parser sees this, and the
> parser does that".  The op never tries to access an instance variable in
> the classs, so the fact that a call to attr_accessor is in the class is
> irrelevant.  End of story.

Hmm...not quite:

class B
end

b = B.new
puts b.a

--output:--
undefined method `a' for #<B:0x253c8> (NoMethodError)


class B
  attr_accessor :a
end

b = B.new
puts b.a

nil
7stud -. (Guest)
on 2009-04-29 03:16
7stud -- wrote:
>> Well, then what's all this talk about "the parser sees this, and the
>> parser does that".

If you do this:

class B
  def a
    @a
  end

  def bar
    "bar"
  end

  def baz
    self.a = "baz"
  end
end

b = B.new
puts b.bar
puts b.a
puts b.baz

--output:--
bar
nil
'baz': undefined method `a=' for #<B:0x24fe0> (NoMethodError)

1) b.a returns nil because the 'a' method exists, but the 'a' method
tries to return a non-existent instance variable @a.

2) The error message is due to the fact that self.a tries to access a
method called a=, which in this class doesn't exist.

If you add the setter method, a=, then the error message goes away:

class B
  def a
    @a
  end

  def a=(val)
    @a = val
  end

  def bar
    "bar"
  end

  def baz
    self.a = "baz"
  end
end

b = B.new
puts b.bar
puts b.a
puts b.baz

--output:--
bar
nil
baz
baz

Note that 'a =' doesn't appear anywhere in the code.  Adding 'a =' in
the body of a method doesn't change anything:

class B
  def a
    @a
  end

  def a=(val)
    @a = val
  end

  def bar
    a = "bar"  #<----****
  end

  def baz
    self.a = "baz"
  end

  def foo
    a = 10
  end
end

b = B.new
puts b.bar
puts b.a
puts b.baz
puts b.a


--output:--
bar
nil
baz
baz


All of which I guess has nothing to do with the op's question.  The op
correctly identified that self.a = "baz" calls the a= method, but that a
= "bar" does not.   I guess I would pose this question to the op: when
have you ever been able to access the a= method in a class without using
the format some_obj.a = ?
7stud -. (Guest)
on 2009-04-29 03:34
7stud -- wrote:
> class B
>   def a
>     @a
>   end
>
>   def a=(val)
>     @a = val
>   end
>
>   def bar
>     a = "bar"  #<----****
>   end
>
>   def baz
>     self.a = "baz"
>   end
>
>   def foo
>     a = 10
>   end
> end
>
> b = B.new
> puts b.bar
> puts b.a
> puts b.baz
> puts b.a
>
>
> --output:--
> bar
> nil
> baz
> baz
>
>
> All of which I guess has nothing to do with the op's question.  The op
> correctly identified that self.a = "baz" calls the a= method, but that a
> = "bar" does not.   I guess I would pose this question to the op: when
> have you ever been able to access the a= method in a class without using
> the format some_obj.a = ?

I guess the idea here:

>   def bar
>     a = "bar"  #<----****
>   end
>
>   def baz
>     self.a = "baz"
>   end

is that when you call a method without a receiver, self is implied.  So
the bar method would be equivalent to:

>   def bar
>     self. a = "bar"  #<----****
>   end
>

Therefore bar and baz have the same format and should do the same thing.
But...

John B. wrote:
> Ruby automatically creates local variables upon
> assignment.

which might be explained further(though perhaps wrongly) by saying:
before ruby can attach 'self.' to the front of 'a' in the bar method:

>   def bar
>     a = "bar"
>   end

the parser tells ruby that it should create a local variable called 'a'
instead and assign it the value on the right of the equals sign.  As a
result unadorned names, for example 'a' vs. 'obj.a', that appear to the
left of an equals sign cause ruby to create a local variable and assign
the local variable the value to the right of the equals sign.
Shaun K. (Guest)
on 2009-04-29 12:11
The short answer would be that

a = 'bar'

is a local variable assignment, whereas

self.a = 'bar'

is an instance variable assignment, like @a
Ryan D. (Guest)
on 2009-04-29 12:36
(Received via mailing list)
On Apr 28, 2009, at 16:34 , 7stud -- wrote:

> is that when you call a method without a receiver, self is implied.
> But...
no. consider local variable assignment to be higher precedence than
message send.

var = val

will ALWAYS be local variable assignment, even if you have #var=.
Florian G. (Guest)
on 2009-04-29 14:08
(Received via mailing list)
On Apr 29, 2009, at 10:11 AM, Shaun K. wrote:

> Posted via http://www.ruby-forum.com/.
>

No,

   a = 'bar'

is local variable assignment, whereas

   self.a = 'bar'

is a method call.

Where #a= was defined through

   attr_accessor :a

and has the side effect of assigning an @variable. It is totally
possible to
implement #a= without having it assign a variable - it is in no way
special.

All you do is force that method call by explicitly mentioning a
receiver.
Brian H. (Guest)
on 2009-04-29 19:29
The second and third posts have made it clear for me.  This is necessary
to allow local variables with the same name as instance variables.  A
contrasting example from a statically typed language makes this more
clear (for me):

(Java)

public class Foo
  private int x;

  public void bar() {
    int x = 2;  // Very obviously a local variable
  }
end

Since Ruby variables are allocated on first use, and Ruby has no
explicit variable declaration syntax, there would be no way to have a
local variable 'x' if an instance variable '@x' existed:

class Foo
  attr_accessor :x

  def bar
    # If this were the same as self.x = 2, or @x = 2,
    # it would not be possible to have a local variable 'x'?
    x = 2
  end
end

Thanks much,

Brian H.
David A. Black (Guest)
on 2009-04-29 19:44
(Received via mailing list)
Hi --

Brian H. wrote:
>    public void bar() {
>
>    def bar
>      # If this were the same as self.x = 2, or @x = 2,
>      # it would not be possible to have a local variable 'x'?
>      x = 2
>    end
> end

Remember, though, that

   @x = 2

and

   obj.x = 2  # where obj may or may not be self

have nothing to do with each other. As Florian said, obj.x = 2 is a
method call (the method being x=).


David
This topic is locked and can not be replied to.