CSC/ECE 517 Fall 2011/ch4 4f sl

CSC/ECE 517 Fall 2010/ch4 4f sl

---

Introduction

One of the many advantages of dynamic languages such as Ruby is the ability to examine aspects of the program from within the program itself. Java calls this feature reflection. This feature is supported by many languages. In languages like Ruby, the classes and Objects exhibit highly dynamic behavior. Probably the most interesting and useful aspect of the use of reflection and Meta-programming is to save the designer from having to write repetitive code.

For instance, sometimes you need to create an instance of class depending upon the parameter passed to a function. This parameter could be the name of the class to be created. One way to accomplish this is to write conditional loops and create the object. But if there are too many classes then this would become messy. This the point where reflection comes to rescue.

The word “reflection” conjures up an image of looking at oneself in the mirror. We use reflection to examine parts of our programs that aren't normally visible from where we stand.

Commonly, Reflection helps us get to know about:

• what objects it contains,

• the current class hierarchy,

• the contents and behaviors of objects, and

• Information on methods.

Reflection allows us to treat classes and methods as objects. Some of the important uses of reflection are:

a. Which methods can be called from an Object?

b. Grab one of the methods of an Object and pass it on to another as a code block.

c. A reference to the module includes.

Basically Reflection allows the user to interactively examine an unfamiliar object or structure.

Reflection in Ruby

There are multiple usages of Reflection in Ruby<ref>The Ruby cookbook by O'reilly publishers</ref>. Some important instances of usage of Reflection in Ruby are shown below:

Finding an Object’s class or super class

Use the Object#class method to get the class of an object as a Class object. Use Class#superclass to get the parent Class of a Class object.

Example:

'a string'.class 					# => String
'a string'.class.name 					# => "String"
'a string'.class.superclass 				# => Object
String.superclass 					# => Object
String.class 						# => Class
String.class.superclass 				# => Module
'a string'.class.new 					# => ""

Ruby doesn’t support multiple inheritance as the language allows mixin Modules that simulate it. The Modules included by a given Class (or another Module) are accessible from the Module#ancestors method.

A class can have only one superclass , but it may have any number of ancestors. Example:

String.superclass 	        # => Object
String.ancestors 		# => [String, Enumerable, Comparable, Object, Kernel]
Array.ancestors 		# => [Array, Enumerable, Object, Kernel]
MyArray.ancestors 	        # => [MyArray, Array, Enumerable, Object, Kernel]
Object.ancestors 		# => [Object, Kernel]

Listing an object’s methods

If there is an unfamiliar object and the user wants to know the supported methods for that object, then he can use the methods call.

Example:

Object.methods
# => ["name", "private_class_method", "object_id", "new",
# "singleton_methods", "method_defined?", "equal?", … ]

The output can also be sorted using the sort method.

Example:

Object.methods.sort
# => ["<", "<=", "<=>", "==", "===", "=~", ">", ">=",
# "__id__", "__send__", "allocate", "ancestors", … ]

We can also list all the public, private and protected methods of a particular object.

Example:

String.private_instance_methods.sort
# => ["Array", "Float", "Integer", "String", "'", "abort", "at_exit",
# "autoload","autoload?", "binding", "block_given?", "callcc", … ]

There is another powerful usage where the user can check if a particular method is supported by the object. This can be done using the Object.respond_to?

Listing all the methods unique to an object

When we check for all the methods available for a class, there are multiple methods which are defined in the object’s super class and mixed-in modules. But, if we need only the methods defined by that object.

Then it can be done by subtracting the instance methods defined by the object’s super class leaving behind only the instance methods defined by the direct class.

Example:

class Object
 def
  my_methods_direct
  my_super = self.class.superclass
  return my_super ? methods - my_super.instance_methods : methods
 end
end

Getting a reference to a method

The Object#methods returns an array of strings, each containing one of the methods supported by that particular object. We can pass any of those object’s method method and get a method object corresponding to that method of that object.

Invoke the method's Method#call method, and it's just like calling the object's method directly.

Example:

1.succ # => 2
1.method(:succ).call # => 2

[1,2,3].method(:each).call { |x| puts x }
# 1
# 2
# 3

A method object can also be stored in a variable and passed onto other methods as arguments. This is useful to implement callbacks and listeners. A method can also be used as a block.

Example:

s = "sample string"
replacements = { "a" => "i", "tring" => "ubstitution" }

replacements.collect(&s.method(:gsub))
# => ["simple string", "sample substitution"]

Fixing bugs in someone else’s code

This is used when you know which method has a bug and you know how to solve the issue, but you don’t have access to that method or don’t want to change the source file.

In this case, we can extend the class from within our program and overwrite the buggy method with our own implementation.

Example: Find the buggy multiplier method :

class Multiplier
 def double_your_pleasure(pleasure)
  return pleasure * 3 # FIXME: Actually triples your pleasure.
 end
end

m = Multiplier.new
m.double_your_pleasure(6) # => 18

Now we can reopen the class, alias the buggy implementation to another name and redefine it again.

class Multiplier
 alias :double_your_pleasure_BUGGY :double_your_pleasure
  def double_your_pleasure(pleasure)
   return pleasure * 2
  end
 end

m.double_your_pleasure(6) # => 12
m.double_your_pleasure_BUGGY(6) # => 18

Responding to calls to undefined methods

Rather than Ruby raising a NoMethodError when someone calls an undefined method, we want to intercept the method call and do something else with that. We can do this by defining a method_missing method for our class. Whenever someone calls a function which is not defined, then method_missing is called.

Example:

class MyClass
  def defined_method
   'This method is defined.'
  end

  def method_missing(m, *args)
   "Sorry, I don't know about any #{m} method."
  end
end

o = MyClass.new
o.defined_method # => "This method is defined."
o.undefined_method
# => "Sorry, I don't know about any undefined_method method."

Most of the times, method_missing is implemented to delegate the implementation of methods to another class. For example, if a class implements method_missing method to catch all such not defined errors and then uses send to delegate it to another object.

These are some of the most important usages of Reflection in Ruby.

Reflection in Java

Use of Reflection

Reflection<ref>http://download.oracle.com/javase/tutorial/reflect/</ref> is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the Java virtual machine. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique<ref>http://java.sun.com/developer/technicalArticles/ALT/Reflection/</ref> and can enable applications to perform operations which would otherwise be impossible.

Extensibility Features

An application may make use of external, user-defined classes by creating instances of extensibility objects using their fully-qualified names.

Class Browsers and Visual Development Environments

A class browser needs to be able to enumerate the members of classes. Visual development environments can benefit from making use of type information available in reflection to aid the developer in writing correct code.

Debuggers and Test Tools

Debuggers need to be able to examine private members on classes. Test harnesses can make use of reflection to systematically call a discoverable set APIs defined on a class, to insure a high level of code coverage in a test suite.

A Simple Example

To see how reflection works, consider this simple example:

   import java.lang.reflect.*;
   public class DumpMethods {
      public static void main(String args[])
      {
         try {
            Class c = Class.forName(args[0]);
            Method m[] = c.getDeclaredMethods();
            for (int i = 0; i < m.length; i++)
            System.out.println(m[i].toString());
         }
         catch (Throwable e) {
            System.err.println(e);
         }
      }
   }

For an invocation of:

  java DumpMethods java.util.Stack

the output is:

  public java.lang.Object java.util.Stack.push(
    java.lang.Object)
   public synchronized 
     java.lang.Object java.util.Stack.pop()
   public synchronized
      java.lang.Object java.util.Stack.peek()
   public boolean java.util.Stack.empty()
   public synchronized 
     int java.util.Stack.search(java.lang.Object) 

Reflection in C++

Use of Reflection

There exist a lot of applications where reflection comes in as a useful technique. So, quite a number of people think that some mechanisms supporting reflection should be added to the next version of C++. Here we present several different aspects of reflection to reflection in C++<ref>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1751.html#APPROACHES</ref>.

Compile-Time Reflection

Compile-time reflection generally provides mechanisms at the source code level. These mechanisms provide information that can be directly derived from the source code, i.e. information about types and their definitions, variables and executable code like expressions or control structures.

This information can then be used to inject or transform code, to instantiate templates or to generate external data: from simple metrics information to full-fledged representations of the source code entities. This external data together with some injected code can then be used to provide such information at runtime.

Runtime Reflection

Runtime reflection provides mechanisms during program execution. Information available generally includes what objects currently exist of a specific class or which variables have which values. But it also comprises typical debugging information like stack frames or even contents of processor registers.

The manipulation mechanisms include changing values, calling functions or creation of new instances of a type, but also modification of existing functions or classes or addition of new ones. Related to debugging, runtime reflection also provides notification mechanisms for events like calling or leaving a function or creation or deletion of an object.

For example:

#include "reflect.h"
#include "typedecl.h"

class A { 
  public:
    int    i;
    char*  pc;
    double d;
  protected:
    long   larr[10];
    A**    ppa;    
    A*     pa;
  public:
    RTTI_DESCRIBE_STRUCT((RTTI_FIELD(i, RTTI_FLD_PUBLIC),
                          RTTI_PTR(pc, RTTI_FLD_PUBLIC),
                          RTTI_FIELD(d, RTTI_FLD_PUBLIC),
                          RTTI_ARRAY(larr, RTTI_FLD_PROTECTED),
                          RTTI_PTR_TO_PTR(ppa, RTTI_FLD_PROTECTED),
                          RTTI_PTR(pa, RTTI_FLD_PROTECTED)));
};

RTTI_REGISTER_STRUCT(A, 0);

Drawbacks of Reflection

General Drawbacks:

Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.

Performance Overhead

Because reflection involves types that are dynamically resolved, certain virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

Security Restrictions

Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

Exposure of Internals

Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.

Limitations of using Reflection either explicitly described by programmer or extracted from debugging info:

In both models of using reflection (explicitly described by programmer and extracted from debugging information) there are some limitations<ref>http://www.garret.ru/cppreflection/docs/reflect.html</ref>. Below we enumerate them grouping in three part - common for proposed reflection API and specific for each approach.

Common limitations to both of the techniques

• It is possible to create instance of the object only using default constructor.

• API doesn't support enums, unions and bit fields.

• API provides type only information only about classes and structures used in the application - no information about global or static functions and variables is available.

Limitation of extracting information from descriptors written by programmer

• Only restricted set of field types is supported (scalars, classes, structures, array and pointers of those types, pointer to pointers to those types).

• Methods can not have more than 5 parameters

• It is not possible to describe static methods and fields.

• Each class should have public default constructor or have no constructors at all.

Limitations of extracting types from debug information

• This approach works only under Unix and most probably only with GCC (because format of mangling symbols is specific to each compiler)

• It is possible to invoke method only at platforms where parameters are passed through the stack (for example Intel). Unfortunately there is no portable way of invoking arbitrary method in C++.

• There is no way to distinguish classes defined in application from system classes which are also extracted from debug information.

• Virtual methods can be invoked only statically (i.e. if you have class A with virtual method foo and class B derived from class A which overrides foo method, get descriptor of A, find method foo in it and invoke this method, then A::foo will be called)

• No field qualifiers (such as const, volatile,...) are currently extracted.

Conclusion

In this wiki page, we describe the reflection feature for object-oriented languages. We focus on introducing the reflection in Ruby, Java and C++ languages. Reflection can be used for observing and/or modifying program execution at runtime. It allows inspection of classes, interfaces, fields and methods at runtime without knowing the names of the interfaces, fields, methods at compile time. It also allows instantiation of new objects and invocation of methods.

References

<references/>