Why shouldn’t we have to declare “l=” as a public method (or at the least, a protected method) so that “m=” can call “self.l=”?

I’m no Ruby guru, but my guess is that then we’d have no way of creating private assignment methods, maybe that’s what “they” are trying to tell us I agree that it’s a weird exception though I don’t know how it could be made any more elegant with the current Ruby syntax.

My mistake. “def m; l; end” does work. I was pointing you in the wrong direction.

I’m kind of following you at this point, but maybe you could expound a bit on this particular aspect of the “discrepency”:

class T
  private
  def l=(val); puts val end

  public
  # I would think that "l=" needs to be
  # 'protected' for this to work:
  def m=(val); self.l=(val) end
end

Now suppose t = T.new:

t.l = 1
# => NoMethodError: private method `l=' called for #

t.m = 1
# => 1

If I understand you correctly, you’re saying this is an anomaly that Ruby intentionally affords us… but why? Why shouldn’t we have to declare “l=” as a public method (or at the least, a protected method) so that “m=” can call “self.l=”?

It just seems like a weird exception to the rules to me. But obviously that’s the way it is, so I’ll adjust

Say you have “def m=(val); l = val; end” then the l variable is simply a local variable, to make it into a method call we need the receiver (self).

Now usually you wouldn’t be able to call a private method with an explicit reciever but with assignment Ruby goes out of it’s way to make sure you can.

The ‘def m; l; end’ suggestion you have there is precisely what I expected to work, which does *not* work.

def m; l; end should work