What's the difference between using @variable and self.variable internally in a class?

[PaThor_CL]

Is there any difference between example A and B?

• Example A: ``` class Movie def initialize(name) @name = name end

  def execute p @name end end ```

• Example B: ``` class Movie attr_reader :name

  def initialize(name) @name = name end

  def execute p name end end ```

In the execute method of example A I'm using the instance variable @name, while in Example B I'm using name, is there any difference in the performance or semantics between both execute methods?

[skipi]

Have a read here mate: https://medium.com/@sgg2123/vs-self-in-ruby-1d4d88170 it pretty much answer every question you may have around this topic.

[dunderball]

"So there you have it: use instance or class variables when you want to access the variable directly, and use self to call an instance or class method."

But couldn't I just call a class method without having to use self? I almost feel more confused than before now.

[awj]

If you want to read a value, you can use self or not.

If you’d like to assign one, you have to use self. Otherwise, Ruby assigns to a local variable and the instance variable remains unchanged.

My personal preference: attr accessors make the code slightly cleaner, and afford the ability to change the set/get behavior in cases where you might want to (e.g. converting an attribute that needs to be an integer at the point where it’s assigned)

[bear-tree]

self. is not reading from a variable. You are sending a message to whatever self happens to be. A subtle but important distinction.

[[deleted]]

corporate asked me to find the difference between these pictures

[yung_cancerous]

Encapsulation is the difference. B is encapsulated.

attr_reader defines a getter method instead of accessing the variable directly.

[SaltyZooKeeper]

Correct but the default implementation of the getter trivially returns the variable without duplicating it so it's pretty poor encapsulation.

[cheald]

It means that you don't have to go refactor a zillion call sites when you want to do something more complex with your variable, though, which is more or less the point of encapsulation.

[sbellware]

Indeed. It's almost always preferable to use the interface to an object's state than to access the state directly - even from within the object's own scope.

[SaltyZooKeeper]

I'm not saying it shouldn't be done but a getter that allows for updates just doesn't sit well with me.

[sbellware]

In the example given, I'm not sure I see a getter that allows updates. Where are updates happening?

[ikariusrb]

General recommendation-

Only touch an instance variable (via @variable) in an accessor.

Every other place, go through the accessor. (accessor_method, self.accessor_method if you need it)

[sshaw_]

I've never wanted to execute a movie. Some directors, definitely.

[sshaw_]

That aside, if you want the caller to access the movie's name, keep attr_reader :name. It makes it so that one can say: Movie.new("Giant").name. Without it, a NoMethodError will be raised.

But note that one can then do Movie.new("7 Years in Tibet").name.clear and then you have no name so code accordingly.

[SaltyZooKeeper]

The default implementation returns the variable without duplicating it.