Why do Ruby setters need "self." qualification within the class?

Question

Ruby setters—whether created by (c)attr_accessor or manually—seem to be the only methods that need self. qualification when accessed within the class itself. This seems to put Ruby alone the world of languages:

• All methods need self/this (like Perl, and I think Javascript)
• No methods require self/this is (C#, Java)
• Only setters need self/this (Ruby?)

The best comparison is C# vs Ruby, because both languages support accessor methods which work syntactically just like class instance variables: foo.x = y, y = foo.x . C# calls them properties.

Here's a simple example; the same program in Ruby then C#:

class A
  def qwerty; @q; end                   # manual getter
  def qwerty=(value); @q = value; end   # manual setter, but attr_accessor is same 
  def asdf; self.qwerty = 4; end        # "self." is necessary in ruby?
  def xxx; asdf; end                    # we can invoke nonsetters w/o "self."
  def dump; puts "qwerty = #{qwerty}"; end
end

a = A.new
a.xxx
a.dump

take away the self.qwerty =() and it fails (Ruby 1.8.6 on Linux & OS X). Now C#:

using System;

public class A {
  public A() {}
  int q;
  public int qwerty {
    get { return q; }
    set { q = value; }
  }
  public void asdf() { qwerty = 4; } // C# setters work w/o "this."
  public void xxx()  { asdf(); }     // are just like other methods
  public void dump() { Console.WriteLine("qwerty = {0}", qwerty); }
}

public class Test {
  public static void Main() {
    A a = new A();
    a.xxx();
    a.dump();
  }
}

Question: Is this true? Are there other occasions besides setters where self is necessary? I.e., are there other occasions where a Ruby method cannot be invoked without self?

There are certainly lots of cases where self becomes necessary. This is not unique to Ruby, just to be clear:

using System;

public class A {
  public A() {}
  public int test { get { return 4; }}
  public int useVariable() {
    int test = 5;
    return test;
  }
  public int useMethod() {
    int test = 5;
    return this.test;
  }
}

public class Test {
  public static void Main() {
    A a = new A();
    Console.WriteLine("{0}", a.useVariable()); // prints 5
    Console.WriteLine("{0}", a.useMethod());   // prints 4
  }
}

Same ambiguity is resolved in same way. But while subtle I'm asking about the case where

• A method has been defined, and
• No local variable has been defined, and

we encounter

qwerty = 4

which is ambiguous—is this a method invocation or an new local variable assignment?

---

@Mike Stone

Hi! I understand and appreciate the points you've made and your example was great. Believe me when I say, if I had enough reputation, I'd vote up your response. Yet we still disagree:

• on a matter of semantics, and
• on a central point of fact

First I claim, not without irony, we're having a semantic debate about the meaning of 'ambiguity'.

When it comes to parsing and programming language semantics (the subject of this question), surely you would admit a broad spectrum of the notion 'ambiguity'. Let's just adopt some random notation:

1. ambiguous: lexical ambiguity (lex must 'look ahead')
2. Ambiguous: grammatical ambiguity (yacc must defer to parse-tree analysis)
3. AMBIGUOUS: ambiguity knowing everything at the moment of execution

(and there's junk between 2-3 too). All these categories are resolved by gathering more contextual info, looking more and more globally. So when you say,

"qwerty = 4" is UNAMBIGUOUS in C# when there is no variable defined...

I couldn't agree more. But by the same token, I'm saying

"qwerty = 4" is un-Ambiguous in ruby (as it now exists)

"qwerty = 4" is Ambiguous in C#

And we're not yet contradicting each other. Finally, here's where we really disagree: Either ruby could or could not be implemented without any further language constructs such that,

For "qwerty = 4," ruby UNAMBIGUOUSLY invokes an existing setter if there
is no local variable defined

You say no. I say yes; another ruby could exist which behaves exactly like the current in every respect, except "qwerty = 4" defines a new variable when no setter and no local exists, it invokes the setter if one exists, and it assigns to the local if one exists. I fully accept that I could be wrong. In fact, a reason why I might be wrong would be interesting.

Let me explain.

Imagine you are writing a new OO language with accessor methods looking like instances vars (like ruby & C#). You'd probably start with conceptual grammars something like:

  var = expr    // assignment
  method = expr // setter method invocation

But the parser-compiler (not even the runtime) will puke, because even after all the input is grokked there's no way to know which grammar is pertinent. You're faced which a classic choice. I can't be sure of the details, but basically ruby does this:

  var = expr    // assignment (new or existing)
  // method = expr, disallow setter method invocation without .

that is why it's un-Ambiguous, while and C# does this:

  symbol = expr // push 'symbol=' onto parse tree and decide later
                // if local variable is def'd somewhere in scope: assignment
                // else if a setter is def'd in scope: invocation

For C#, 'later' is still at compile time.

I'm sure ruby could do the same, but 'later' would have to be at runtime, because as ben points out you don't know until the statement is executed which case applies.

My question was never intended to mean "do I really need the 'self.'?" or "what potential ambiguity is being avoided?" Rather I wanted to know why was this particular choice made? Maybe it's not performance. Maybe it just got the job done, or it was considered best to always allow a 1-liner local to override a method (a pretty rare case requirement) ...

But I'm sort of suggesting that the most dynamical language might be the one which postpones this decision the longest, and chooses semantics based on the most contextual info: so if you have no local and you defined a setter, it would use the setter. Isn't this why we like ruby, smalltalk, objc, because method invocation is decided at runtime, offering maximum expressiveness?

Roadblock

PHP also requires $this-> when accessing instances variables. That trips me up all the time. – Jean

An explicit receiver is only needed for class methods, not instance methods. – Nutriment

I agree – I also don't like this method of resolving the amibuity. Violates the principle of least surprise. – Opuntia

@Opuntia Matz clarifies what he means by least surprise: Everyone has an individual background. ...they may be surprised by different aspects of the language. Then they come up to me and say, "I was surprised by this feature of the language, so therefore Ruby violates the principle of least surprise." Wait. Wait. The principle of least surprise is not for you only. The principle of least surprise means principle of least my surprise. And it means the principle of least surprise after you learn Ruby very well. – Allegra

Answer 1

The important thing to remember here is that Ruby methods can be (un)defined at any point, so to intelligently resolve the ambiguity, every assignment would need to run code to check whether there is a method with the assigned-to name at the time of assignment.

Nominee

This is not correct, real reason is that simply stating x=5 instantiates a local variable x which overrides any existing setter self.x=. To resolve this ambiguity, if you want to call setter x= you need to explicitly say what you want to do by stating self.x= – Lyallpur

Answer 2

Well, I think the reason this is the case is because qwerty = 4 is ambiguous—are you defining a new variable called qwerty or calling the setter? Ruby resolves this ambiguity by saying it will create a new variable, thus the self. is required.

Here is another case where you need self.:

class A
  def test
    4
  end
  def use_variable
    test = 5
    test
  end
  def use_method
    test = 5
    self.test
  end
end
a = A.new
a.use_variable # returns 5
a.use_method   # returns 4

As you can see, the access to test is ambiguous, so the self. is required.

Also, this is why the C# example is actually not a good comparison, because you define variables in a way that is unambiguous from using the setter. If you had defined a variable in C# that was the same name as the accessor, you would need to qualify calls to the accessor with this., just like the Ruby case.

Theirs

Answer 3

Because otherwise it would be impossible to set local variables at all inside of methods. variable = some_value is ambiguous. For example:

class ExampleClass
  attr_reader :last_set
  def method_missing(name, *args)
    if name.to_s =~ /=$/
      @last_set = args.first
    else
      super
    end
  end

  def some_method
    some_variable = 5 # Set a local variable? Or call method_missing?
    puts some_variable
  end
end

If self wasn't required for setters, some_method would raise NameError: undefined local variable or method 'some_variable'. As-is though, the method works as intended:

example = ExampleClass.new
example.blah = 'Some text'
example.last_set #=> "Some text"
example.some_method # prints "5"
example.last_set #=> "Some text"

Inedible

Haha. I was about to upvote this answer, then realized it was mine from a year ago. ;-) – Inedible

I think this is the only answer that clearly states why you can't ever go without self.. – Escutcheon

I should add to that, the reason Java and its ilk get away with it, is because as statically typed languages, the compiler can determine in advance if there is going to be a conflict, and raise an appropriate error accordingly. Dynamic (scripting languages), weak typed (php) and duck typed (ruby/python) languages have no such luxury, alas – Timothea