Digging Deeper

Here you will learn more about the visibility of code inside methods and another way of defining singleton methods.

Protected and Private Methods in Descendant Classes

The same access rules described in this chapter also apply when calling the methods of ancestor and descendant objects. That is, when you pass an object to a method (as an argument) that has the same class as the receiver object (in other words, the object to which the method belongs), the argument object can call the public and protected methods of the class but not its private methods.

For an example of this, take a look at the protected.rb program. Here I have created a MyClass object called myob and a MyOtherClass object, myotherob, where MyOtherClass descends from MyClass:

protected.rb

class MyClass

    private
        def priv( aStr )
            return aStr.upcase
        end

    protected
        def prot( aStr )
            return aStr << '!!!!!!'
        end

    public

        def exclaim( anOb )  # calls a protected method
            puts( anOb.prot( "This is a #{anOb.class} - hurrah" ) )
        end

        def shout( anOb )    # calls a private method
            puts( anOb.priv( "This is a #{anOb.class} - hurrah" ) )
        end

end

class MyOtherClass < MyClass

end

class MyUnrelatedClass

end

I now create objects from each of these three classes, and I try to pass myotherob as an argument to the myob public method, shout:

myob = MyClass.new
myotherob = MyOtherClass.new
myunrelatedob = MyUnrelatedClass.new

If you load this program from the code archive, you will see that it contains a number of lines of code in which these three objects attempt to execute the shout and exclaim methods. Many of these attempts are doomed to failure and so have been commented out. However, when testing the code, you may want to uncomment each method call one by one to see the results. This is my first attempt:

myob.shout( myotherob )     # fails

Here the shout method calls the private method priv on the argument object:

def shout( anOb )    # calls a private method
   puts( anOb.priv( "This is a #{anOb.class} - hurrah" ) )
end

This won’t work! Ruby complains that the priv method is private.

Similarly, were I to do it the other way around—that is, by passing the ancestor object myob as the argument and invoking the method shout on the descendant object—I would encounter the same error:

myotherob.shout( myob )     # fails

The MyClass class also has another public method, exclaim. This one calls a protected method, prot:

def exclaim( anOb )  # calls a protected method
   puts( anOb.prot( "This is a #{anOb.class} - hurrah" ) )
end

Now, I can pass either the MyClass object, myob, or the MyOtherClass object, myotherob, as an argument to the exclaim method, and no error will occur when the protected method is called:

myob.exclaim( myotherob )        # This is OK
myotherob.exclaim( myob )        # And so is this...
myob.exclaim( myunrelatedob )    # But this won't work

Needless to say, this works only when the two objects (the receiver object to the left of the dot and the argument passed to the method) share the same line of descent. If you send an unrelated object as an argument, you would not be able to call methods of the receiver class, no matter what their protection levels.

Invading the Privacy of Private Methods

The whole point of a private method is that it cannot be called from outside the scope of the object to which it belongs. So, this won’t work:

send.rb

class X
    private
        def priv( aStr )
             puts("I'm private, " << aStr)
        end
end

ob = X.new
ob.priv( "hello" )      # This fails

However, it turns out that Ruby provides a “get out clause” (or maybe I should say a “get in” clause?) in the form of a method called send.

The send method invokes the method whose name matches that of a symbol (an identifier beginning with a colon such as :priv), which is passed as the first argument to send like this:

ob.send( :priv, "hello" )    # This succeeds

Any arguments supplied after the symbol (like the string “hello”) are passed in the normal way to the specified method.

Using send to gain public access to a private method is not generally a good idea. After all, if you need access to a certain method, why make it private in the first place? Use this technique with caution or not at all.

Singleton Class Methods

Earlier, I created class methods by appending a method name to the name of the class like this:

def MyClass.classMethod

There is a “shortcut” syntax for doing this. Here is an example:

class_methods3.rb

class MyClass

   def MyClass.methodA
      puts("a")
   end

   class << self
      def methodB
         puts("b")
      end

      def methodC
         puts("c")
      end
   end

end

Here, methodA, methodB, and methodC are all class methods of MyClass; methodA is declared using the syntax used previously:

def ClassName.methodname

But methodB and methodC are declared using the syntax of instance methods:

def methodname

So, why do they end up as class methods? It’s all because the method declarations have been placed inside this code:

class << self
    # some method declarations
end

This may remind you of the syntax used for declaring singleton classes. For example, in the singleton_class.rb program, you may recall that I first created an object named ob and then gave it its very own method, blather:

class << ob
   def blather( aStr )
      puts("blather, blather #{aStr}")
   end
end

The blather method here is a singleton method of the ob object. Similarly, in the class_methods3.rb program, the methodB and methodC methods are singleton methods of self—and self happens to be the MyClass class. You can similarly add singleton methods from outside the class definition by using << followed by the class name, like this:

class << MyClass
   def methodD
      puts( "d" )
   end
end

Finally, the code checks that all four methods really are singleton methods by first printing the names of all available singleton methods and then calling them:

puts( MyClass.singleton_methods.sort )
MyClass.methodA
MyClass.methodB
MyClass.methodC
MyClass.methodD

This displays the following:

methodA
methodB
methodC
methodD
a
b
c
d

Nested Methods

You can nest methods; that is, you can write methods that contain other methods. This gives you a way of dividing a long method into reusable chunks. So, for example, if method x needs to do calculation y at several different points, you can put the y method inside the x method (the methods in the following example are called outer_x, nested_y, and nested_z for clarity):

nested_methods.rb

class X

   def outer_x
      print( "x:" )

      def nested_y
         print("ha! ")
      end

      def nested_z
         print( "z:" )
         nested_y
      end

      nested_y
      nested_z
   end

end

Nested methods are not initially visible outside the scope in which they are defined. So, in the previous example, although nested_y and nested_z may be called from inside outer_x, they may not be called by any other code:

ob = X.new
ob.outer_x         #=> x:ha! z:ha!

If, instead of ob.outer_x in the previous code, you were to call ob.nested_y or ob.nested_z, you would see an error message since the nested_y and nested_z methods would not, at this stage, be visible. However, when you run a method that encloses nested methods, those nested methods will be brought into scope outside that method!

nested_methods2.rb

class X
   def x
      print( "x:" )
      def y
         print("y:")
      end

      def z
         print( "z:" )
         y
      end
   end
end


ob = X.new
ob.x        #=> x:
puts
ob.y        #=> y:
puts
ob.z        #=> z:y:

To see another example of this, try running the nested_methods.rb code again, but this time uncomment all three method calls. This time, when the outer_x method executes, it brings nested_y and nested_z into scope so the calls to the two nested methods now succeed:

ob.outer_x     #=> x:ha! z:ha!
ob.nested_y    #=> ha!
ob.nested_z    #=> z:ha!

Method Names

As a final point, it’s worth mentioning that method names in Ruby almost always begin with a lowercase character like this:

def fred

However, that is a convention, not an obligation. It is also permissible to begin method names with capital letters, like this:

def Fred

Since the Fred method looks like a constant (it starts with a capital letter), you would need to tell Ruby that it is a method when calling it by adding parentheses:

method_names.rb

Fred         # <= Ruby complains 'uninitialized constant'
Fred()       # <= Ruby calls the Fred method

On the whole, it is better to stick to the convention of using method names that begin with a lowercase character.