CSC/ECE 517 Fall 2012/ch1 1w31 sa

Closures and Methods:

Introduction

This article helps in understanding the concepts of Closures and Methods and also provides a comparison between the two.

In Statically typed languages, methods (also known as procedures or functions) are a set of instructions that perform a specific task. The main objective of methods is to provide reusability of code. Methods can be used to retrieve the state of an object i.e. object’s instance variables. Existence for methods is tied to life time of Objects to which they belong. But many a times there are certain problem domains, where methods are not enough to provide a flexible, elegant implementation and we need the state of a variable to persist even when it is not in the scope of currently running method. One such elegant mechanism which comes out handy in situations as such is Closure.

Closures are blocks of code that can be passed around like objects, which have the property that they are "bound" to the context (or state of the program) in which they were created and therefore are not dependent on the presence of object or functions which created it.

Methods

A Method is a Subroutine (or Procedure or Function) in a class that defines the behaviour exhibited by the associated Class instances at runtime. Methods defined within a Class are bound to the class either by Static or Dynamic binding.

Following is a Ruby example that shows how methods can be used to statically bind to the state of an object:

class Account
 def initialize(default)
   @balance = default
 end
 
 def get_balance
   @balance
 end
 
 def set_balance(value)
   @balance = value
 end
end

account1 = Account.new(100)
puts account1.get_balance  #prints 100
account1.set_balance(200)
puts account1.get_balance  #prints 200

Here the methods are statically bound to the object account1 and have access to its state as long as this object is in existence.

Different types of methods

Instance methods Instance methods are the methods which are bound to objects of the class i.e. there creation depends on creation of object. Instance methods can access instance variables and instance methods directly. Instance methods can also access class variables and class methods directly. Static methods These are also known as Class methods as they belong to the whole class and not a instances or objects in the class. We need these methods if we don’t want a particular functionality to be dependent on creation of objects. Class methods can access class variables and class methods directly. Class methods cannot access instance variables or instance methods directly i.e. they must use an object reference. Also, class methods cannot use this keyword as there is no instance for this to refer to. For Ex :- In Java we have a method public static void main(Strings args[]) This method is where the interpreter starts reading the code and this is a static method because this is the first method that is called when we try to execute the class and at that time there are no objects created. Accessor methods Accessor methods are a instance method with the aim to get or set the value of instance variables. Object oriented languages provide the way to hide the instance variables associated with object to outside world by means of encapsulation i.e. marking the instance variables private. So any object can’t access the instance variables of a class directly, this is where accessor methods come into picture. They are the methods through which an object can access the instance variables and we can define some rules in these methods which should be fulfilled in order to set or get these variables. Example: In following Java class weight is an instance variable and is marked private so that any object can’t directly set its value to some incorrect state. Like weight can’t be negative.

Class Person
{
    private int weight;
    public int getWeight()
    {
    }
    public int setWeight(weight)
    {
        if(weight < 0)
        {
             // Some error
        }
        else
        {
            this.weight = weight;
        }
    }
}

Instance methods

The object of a class receives a method name to be executed, the following steps are carried out for matching and executing the method:

• First, the object looks in its own instance methods.
• Second, it looks in the list of instance methods that all objects of that class share.
• Third, in each of the included modules of that class, in reverse order of inclusion.
• Fourth, it looks in that class’s superclass.
• Fifth, in the superclass’s included modules, all the way up until it reaches the class Object.
• Sixth, if it still can’t find a method, the very last place it looks is in the Kernel module, included in the class Object.
• Finally, it calls method_missing (if defined in the class), else throws up the NOMethodError exception.

This entire tracing that the object does is the method lookup path.

Examples

Calling defined and undefined methods

class A		// creating a class 'A'
def say		// defining a method 'say'
puts " say Hi " // body of method say
end
end

Creating the object of the class

 a=A.new	       // object of the class
 => #<A:0x2a082e0>     //object id

Calling the defined method

a.say                  // defined method
=> say Hi	       // returned result

Calling the undefined method

a.sayhi                // undefined method sayhi
NoMethodError: undefined method `sayhi' for #<A:0x2a082e0>   // the NoMethodError is raised

method_missing implementation<ref>http://www.thirdbit.net/articles/2007/08/01/10-things-you-should-know-about-method_missing/</ref>

class A
def say
puts " say hi "
end
def method_missing(m,*args,&block)	// defining method_missing
puts " This method does not exist"	// body of method_missing
end
end

Calling a method that is not defined

a=A.new
a.sayhi                                // calling the undefined method sayhi with no arguments
=> This method does not exist		// this result returned when method_missing is executed

When the object 'a' traces its method lookup path for a matching method as 'sayhi', upon failure it resorts to method_missing and the body of method_missing is executed. 'method_missing' is the last resort.

Sometimes when a class has many methods that do generally the same kinds of things, and the programmer is not sure in advance which methods the user will call since there are so many of them, and they are all so similar, implementing all of them by hand seems futile. In these situations method_missing makes a new method that was previously not defined and adds it to the class. The below 'Generic Handler' example implements this.

passing parameters to an undefined method call

class A
def add(a,b)
a+b
end
def method_missing(name,*args,&block)    // the method_missing is defined and the *args parameter accepts all the parameters passed during 								                                 
                                            the method call   
puts “You have typed the method name wrong and these were the parameters passed ; #{args[0]}, #{args[1]}”								
end                         			
end

The passed parameters are stored in the array 'args' and can be accessed like a normal array

Calling the defined method

a.add(1,2)		        // calling the defined method add and passing the parameters (1,2)
=> 3                           // result

Calling the undefined method

a.adds(4,2) 			// calling the undefined method adds and passing the parameter (4,2)
=> You have typed the method name wrong and these were the parameters passed; 4, 2

The user made a genuine mistake by typing 'adds', but this method is not defined. When the 'adds' method with parameters is called, the object 'a' tries to match the method in the method lookup path. Upon failure it invokes method_missing, the args are passed, stored in the array 'args' and the body of method_missing is executed.

converting numbers from roman representation to integer representation<ref>http://www.rubyquiz.com/quiz22.html</ref>

class Roman
@@Roman_to_Numeric = {'i' => 1, 'v' => 5, 'x' => 10, 'l' => 50, 'c' => 100, 'd' => 500, 'm' => 1000}   
def method_missing(method_var,*args,&block)
numeric_value = 0
roman_string = method_var.to_s.downcase
for i in 0...roman_string.length-1
if (cond) == nil
else
puts "Roman string is invalid"
return
end
end
while roman_string != ""
if roman_string[roman_string.length - 1] == 'x' && roman_string[roman_string.length - 2] == 'i'
numeric_value += 9
roman_string.chop!
roman_string.chop!
elsif
roman_string[roman_string.length - 1] == 'v' && roman_string[roman_string.length - 2] == 'i'
numeric_value += 4
roman_string.chop!
roman_string.chop!
else
numeric_value += @@Roman_to_Numeric[roman_string[(roman_string.length)-1]]
roman_string.chop!
end
end
puts "Numeric Value for #{method_var} is: #{numeric_value}"
end
end

cond = [@@Roman_to_Numeric[roman_string[i]]-@@Roman_to_Numeric[roman_string[i+1]] == 0 || @@Roman_to_Numeric[roman_string[i]]-@@Roman _ to_ Numeric [ roman _ string [ i + 1 ] ] == - 9 || @@Roman_to_Numeric[roman_string[i]]-@@Roman_to_Numeric[roman_string[i+1]] == -4 || @@Roman_to_Numeric[roman_string[i]]-@@Roman_to_Numeric[roman_string[i+1]] >= 4) && (/.v.x/ =~ roman_string]

Calling the undefined methods

r= Roman.new
r.vii
r.iClx
r.xxix
r.xxxi
r.xxiv
r.xxvi
r.vx

The Output

Numeric Value for vii is: 7
Roman string is invalid
Numeric Value for xxix is: 29
Numeric Value for xxxi is: 31
Numeric Value for xxiv is: 24
Numeric Value for xxvi is: 26
Roman string is invalid

method_missing to log method calls<ref>http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2007/wiki1b_2_22</ref>

Another application that makes use of method_missing could be a simple logger used for debugging purposes. Many times, it may be required to log the trace of called methods and provide information such as: called method-name, arguments, return type. It can be tedious to repeat this part of code in every method. A simple solution to this problem can be obtained using method_missing as:

 class SimpleCallLogger
 def initialize(o)
 @obj = o
 end
 def method_missing(methodname, *args)
 puts "called: #{methodname}(#{args})"
 a = @obj.send(methodname, *args)
 puts "\t-> returned: #{a}"
 return a
 end
 end

This program makes use of method_missing in a way that it wraps around called method to output the logging information on entry and on exit, it logs the return type. Further, method_missing intercepts the method call and forward it to internal object with ‘send’ method of ruby. Hence, this use of method_missing acts as wrapper.

Generic Handler

class NoBar
def method_missing(methodname, *args)
define_method(:bar) if "bar" == methodname.to_s
define_method(:nobar) if "nobar" == methodname.to_s
end
end

This is an example of using method_missing as a generic handler to handle when a calling method is not exist. You can use missing_method to dynamically create a method at a runtime.

Advantages of method_missing

• In addition to specifying the error messages for the undefined methods, method_missing provides a more dynamic behavior in the programming environment.
• If we are unfamiliar with the usage of the objects we created, then using method_missing is a good technique.
• Handles problems at runtime.
• Define's a generic method_missing and handle's any undefined method, a big advantage over Java. In Java, when you call an undefined method, the program will not compile.
• method_missing falls under the general technique of meta-programming. Employ meta-programming in missing_function to write an another function to handle the call.

Disadvantages of method_missing

• Slower than conventional method lookup. Simple tests indicate that method dispatch with method_missing is at least two to three times as expensive in time as conventional dispatch.

• Since the methods being called never actually exist—they are just intercepted at the last step of the method lookup process—they cannot be documented or introspected as conventional methods can.

• Dynamic methods must go through the method_missing method, the body of that method can become quite large if there are many different aspects of the code that needs to add methods dynamically.

• method_missing restricts compatibility with future versions of an API. Introducing new methods in a future API version can break users' expectations.

Key Points

• Ruby knows method_missing( ) exisits, because it's a private instance method of 'BasicObject' that every object inherits. The BasicObject#method_missing( ) responds by raising the NoMethodError. Overriding this method_missing( ) allows you to call methods that don't really exist.

• If method_missing is only looking for certain method names, don't forget to call the super keyword if you haven't found what you're looking for, so that the other superclass' method_missing can handle it.

• obj.respond_to? function returns 'true' if the obj responds to the given method. So if you want to know whether your class will respond to a function you can use respond_to? to know the answer. But if method_missing() is used, the output may not be what you expect.

• Below class A defines only method method_missing() and no other method. When a new object of class A tries to access a method say 'foo', the respond_to? will return the value 'false'. When you actually try to implement it using “a.foo”, the code will get executed, courtesy of method_missing(). Even though the respond_to? says that you cannot access 'foo' method using object of class A, if you have method_missing() defined, you can access the method.

class A
def method_missing(method_id)
puts "In method_missing"
end
end

a = A.new
puts a.respond_to?(:foo)
a.foo

Output

false
In method_missing

• If within method_missing() we define an undefined method.

class A
@@i = 0
def method_missing(method_id)
puts "In Method Missing #{@@i}"
@@i += 1
self.fun
end
end

a = A.new
puts a.respond_to?(:foo)	// just checking whether the receiver 'a' responds to the method 'foo'

a.foo 

Output

The expected result would be a 'stack level too deep' error. 

When the 'foo' method is called, after no method match the method_missing is run and this block has a method “self.fun” that is undefined. Here when the program execution encounters 'self.fun' it once again calls method_missing. This goes on in an endless loop till the stack memory is full.

References

<references/>

Further Suggested Reading

• http://www.rubyinside.com/
• http://blog.jayfields.com/2008/02/ruby-replace-methodmissing-with-dynamic.html
• http://liquiddevelopment.blogspot.com/2006/04/twisting-and-shaping-dsls-using-ruby.html
• http://blog.rubybestpractices.com/posts/gregory/031-issue-2-method-lookup.html
• http://phrogz.net/RubyLibs/RubyMethodLookupFlow.pdf