CSC/ECE 517 Spring 2013/ch1b 1n jp

Ruby's method_missing(): Advantages/Disadvantages and Alternatives

Introduction

One of the distinguishing features of the Ruby programming language is it's ability to easily extend classes in a dynamic fashion to perform a variety of different methods depending upon the needs of the current application. For example, should the developer want to extend a core language class, take String for example, they could easily re-open that class and add new methods dynamically to this existing class, rather than creating an entirely new class.

Even more powerful, Ruby allows for a construct called method_missing(). By overriding this method in your class, method_missing() will attempt to handle any method calls not currently defined by the given class (or class hierarchy). Typically, some sort of regular expression is used to determine if the method call can be redirected to an existing method based on it's naming convention (for example, a method call in a non-existent singular form could be redirected to an existing pluralized form). If the method_missing() definition cannot determine where to redirect the method call, the default is simply to call the parent class via super().

By having the ability to allow a class to dynamically extend itself even if a method definition never truly existed, Ruby allows for a far greater degree of flexibility than does a statically typed language such as Java, where much greater effort is involved in handing method calls that do not currently exist. With method_missing() defined, almost any sort of method call can be handled in the desired manner.

This article will explore the method_missing() construct in greater detail, giving both advantages and disadvantages of having this feature in the Ruby language. We will also examine how other programming languages attempt to handle the same problem.

Advantages of method_missing()

1. Allows for dynamically invoked methods.

Alternatives to method_missing() in other programming languages

Smalltalk: doesNotUnderstand

In many ways the inspiration for Ruby, Smalltalk is often considered one of the original truly Object-Oriented languages. Smalltalk, much like Ruby with method_missing(), sends a message called #doesNotUnderstand<ref>http://c2.com/cgi/wiki?DoesNotUnderstand</ref> to handle methods that are unknown.

Essentially, when an object receives a method that it doesn't recognize, the Smalltalk runtime engine is then responsible for turning this message into an object with all necessary parameters and returning it to the sender as an exception. The sender is, at that point, responsible for handling the message and somehow dealing with the exception. Even though Smalltalk does consider this an exception, this construct is used quite frequently to form proxy objects and can handle a wide variety of different methods and arguments.

Consider the following code: <ref>http://www.iam.unibe.ch/~akuhn/blog/category/smalltalk/</ref>

   OrderedCollection subclass: #Group.
   Group >> eachRespondsTo: aSelector
       self allSatisfy: [ :each | each respondsTo: aSelector ]
   Group >> doesNotUnderstand: aMessage
       (self eachRespondsTo: aMessage selector)
         ifTrue: [ self collect: [ :each | aMessage sendTo: each ] ]
         ifFalse: [ super doesNotUnderstand: aMessage ]
   Group >> respondsTo: aSelector
     ^ (super respondsTo: aSelector) or: [ self eachRespondsTo: aSelector ]

In this code snippet, an OrderedCollection object is created. Should this collection class not understand any of the methods being sent to it, the doesUnderstand code will attempt to handle the message itself. Without overriding this method, the default is for Smalltalk to open a debugger to step through the exception (defining it overrides this behavior).

Java: DynamicProxy

In Java, the ability to handle undefined methods is a bit more cumbersome, but it can still be done successfully through the use of dynamic proxy classes.<ref>http://www.jroller.com/ie/entry/methodmissing_in_java</ref>

References

<references />