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 Metaprogramming 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

Comments for the program:
The above program is used to list all the methods unique to the object. Here it finds out all the methods and subtracts all the Super class methods.

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"]

Dynamic Binding

When designing a system it is often the case that developers:

1. Know what class interfaces they want, without precisely knowing the most suitable representation.

2. Know what algorithms they want, without knowing how particular operations should be implemented.

In both cases, it is often desirable to defer certain decisions as long as possible.

– Goal: reduce the effort required to change the implementation once enough information is available to make an informed decision.

Dynamic binding allows applications to be written by invoking general methods via a base class pointer, e.g.,

class Base { public: virtual int vf (void); };
Base *bp = /* pointer to a subclass */;
bp->vf ();

However, at run-time this invocation actually invokes more specialized methods implemented in a derived class, e.g.,

class Derived : public Base
{ 
     public: virtual int vf (void); 
};
Derived d;
bp = &d;
bp->vf (); // invokes Derived::vf()

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<ref>http://www.runrev.com/products/livecode/visual-development-environment/</ref>

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)

Drawbacks in Java

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.

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 in C++

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.

Reflection drawbacks in general

In general, there are several drawbacks of using reflection in object-oriented programming languages:

Lose all the compile-check features, consequently lose in performance.

There are also some security restrictions to call reflection methods.

Lots of boilerplate codes, comes at a speed cost.

Summary of the Article

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 provides objects that encapsulate assemblies, modules, and types. You can use reflection to dynamically create an instance of a type, bind the type to an existing object, or get the type from an existing object. You can then invoke the type's methods or access its fields and properties. There are also some drawbacks for using reflection we metioned above. In all, reflection is a very useful tool for OOP languages.

References

External links

An Introduction to Reflection-Oriented Programming
Brian Foote's pages on Reflection in Smalltalk
Java Reflection Tutorial from Sun Microsystems
Reflection for computer programming
Applets
Dynamic Binding

CSC/ECE 517 Fall 2011/ch4 4f sl

Contents

Introduction

Reflection in Ruby

Finding an Object’s class or super class

Listing an object’s methods

Listing all the methods unique to an object

Getting a reference to a method

Dynamic Binding

Fixing bugs in someone else’s code

Responding to calls to undefined methods

Reflection in Java

Use of Reflection

Drawbacks in Java

Reflection in C++

Use of Reflection

Drawbacks in C++

Reflection drawbacks in general

Summary of the Article

References

External links

Further reading

Navigation menu

CSC/ECE 517 Fall 2011/ch4 4f sl

Introduction

Reflection in Ruby

Finding an Object’s class or super class

Listing an object’s methods

Listing all the methods unique to an object

Getting a reference to a method

Dynamic Binding

Fixing bugs in someone else’s code

Responding to calls to undefined methods

Reflection in Java

Use of Reflection

Drawbacks in Java

Reflection in C++

Use of Reflection

Drawbacks in C++

Reflection drawbacks in general

Summary of the Article

References

External links

Further reading

Navigation menu

Search