Useful inconcistency in calling foo vs. foo= private methods

Ruby
1

Hi

This is an interesting sort of useful gotcha I recently stumbled upon:

class Foo
private

def bar
p ‘#bar called’
end
def bar=(val)
p ‘#bar= called’
end
end

irb(main):002:0> foo = Foo.new
irb(main):003:0> foo.instance_eval { self.bar }
NoMethodError: private method `bar’ called for #Foo:0x2c85a68
irb(main):004:0> foo.instance_eval { self.bar = 1 }
“#bar= called”

Formally, the the last line should have thrown an exception as well;
afaik private methods can’t by definition be called with an explicit
receiver. It seems the assignment methods are exempt from this rule.
This is actually useful, since it overrides the higher precendence of
local variable assignment over method calls; if self.bar= didn’t work,
I don’t see any way short of self.send to call the private #bar=.

Still I thought it might be worth mentioning.

2

On Fri, 30 Jun 2006, Alder G. wrote:

def bar=(val)
Formally, the the last line should have thrown an exception as well;
afaik private methods can’t by definition be called with an explicit
receiver. It seems the assignment methods are exempt from this rule.
This is actually useful, since it overrides the higher precendence of
local variable assignment over method calls; if self.bar= didn’t work,
I don’t see any way short of self.send to call the private #bar=.

a useful idiom

class Foo
private

 def bar *a
   if a.size == 0
     @bar
   else
     __send__ 'bar=', a.shift
   end
 end
 def bar= val
   @bar = val
 end

end

Foo.new.instance_eval{ bar 42 }

it avoids the issue somewhat.

regards.

-a