When use self.method_name and when only method_name?

Ruby
1

Hi all

Just a small newbie question: When calling a method inside an object, I
should always use self.method_name for good style, right? I know that I
could always only use “method_name”, but it’s a bit prone to errors
because I could have also a local variable called “method_name”, and
when I use “self.” I always call the method, and not a potentially
available local variable.

So it’s always better style to use:

def validate
self.errors.add_to_base("…")
end

instead of:

def validate
errors.add_to_base("…")
end

Right? :slight_smile:

Thanks
Josh

2

Hi –

On Sun, 11 Oct 2009, Joshua M. wrote:

Right? :slight_smile:
In general I prefer to leave off the optional “self.” except in a
couple of cases. The one that comes to mind mainly is:

def <=>(other)
self.age <=> other.age
end

where I like having the explicit receiver on both sides.

It’s definitely not unidiomatic to leave off the self. In fact, the
whole private access level depends on it – and even if you’re not
using a lot of private methods, that’s enough to confirm that it’s
acceptable stylistically.

David

–
The Ruby training with D. Black, G. Brown, J.McAnally
Compleat Jan 22-23, 2010, Tampa, FL
Rubyist http://www.thecompleatrubyist.com

David A. Black/Ruby Power and Light, LLC (http://www.rubypal.com)

3

David A. Black wrote:

In fact, the
whole private access level depends on it

What do you mean with this exactly?

4

Joshua M. wrote:

Just a small newbie question: When calling a method inside an object, I
should always use self.method_name for good style, right? I know that I
could always only use “method_name”, but it’s a bit prone to errors
because I could have also a local variable called “method_name”, and
when I use “self.” I always call the method, and not a potentially
available local variable.

It’s good style to keep methods small. Remember that every method starts
with a clean sheet of local variables - they never propagate in from
outside - so it’s obvious by inspection whether a name is a local
variable or not.

But there is a much larger class of errors such as simple typos:

self.method_nmae
slef.method_name

You’ll need unit tests to counter these; and once you have them, these
will also cover other logic errors including the accidental shadowing of
a method with a local variable as you describe above.

BTW, I still sometimes write
foo = xxx

when I mean to call the method,
self.foo = xxx

I suppose writing ‘self.’ everywhere would make that less likely - but
I’d still say it’s better to have good unit tests.

5

Hi –

On Sun, 11 Oct 2009, Joshua M. wrote:

David A. Black wrote:

In fact, the
whole private access level depends on it

What do you mean with this exactly?

A private method can only be called without an explicit receiver
(except for =-terminated methods). For example:

class Baker
def bake_cake
make_batter # private method
put_in_oven # private method
puts “Cake is done!”
end

 private
 def make_batter
   puts "Privately making the batter!"
 end

 def put_in_oven
   puts "Privately putting the cake in oven!"
 end

end

b = Baker.new
b.bake_cake

In this code, I can call the private methods only when I don’t have
an explicit receiver, including self. If I try to do this:

b.make_batter

I get an error. Also, if I rewrite bake_cake like this:

def bake_cake
self.make_batter
put_in_oven
puts “Cake is done!”
end

I get an error, because I’m calling make_batter with an explicit
receiver.

So Ruby uses the bareword style of method call to enforce privateness.
The exception is the setter methods (like age=), which always require
an explict receiver. In such cases, the receiver must be “self” (i.e.,
exactly the word “self”, not a variable reference to self).

David

–
The Ruby training with D. Black, G. Brown, J.McAnally
Compleat Jan 22-23, 2010, Tampa, FL
Rubyist http://www.thecompleatrubyist.com

David A. Black/Ruby Power and Light, LLC (http://www.rubypal.com)