Reflection (computer science):

In computer science, reflection is the process by which a computer program can observe and modify its own structure and behaviour. The programming paradigm driven by reflection is called reflective programming. It is a particular kind of metaprogramming.

In most modern computer architectures, program instructions are stored as data - hence the distinction between instruction and data is merely a matter of how the information is treated by the computer and programming language. Normally, 'instructions' are 'executed' and 'data' is 'processed'; however, in some languages, programs can also treat instructions as data and therefore make reflective modifications. Reflection is most commonly used in high-level virtual machine programming languages like Smalltalk and scripting languages, and less commonly used in manifestly typed and/or statically typed programming languages such as Java and C.

Reflection-oriented programming

Reflection-oriented programming, or reflective programming, is a functional extension to the object-oriented programming paradigm. Reflection-oriented programming includes self-examination, self-modification, and self-replication. However, the emphasis of the reflection-oriented paradigm is dynamic program modification, which can be determined and executed at runtime. Some imperative approaches, such as procedural and object-oriented programming paradigms, specify that there is an exact predetermined sequence of operations with which to process data. The reflection-oriented programming paradigm, however, adds that program instructions can be modified dynamically at runtime and invoked in their modified state. That is, the program architecture itself can be decided at runtime based upon the data, services, and specific operations that are applicable at runtime.

Programming sequences can be classified in one of two ways, atomic or compound. Atomic operations are those that can be viewed as completing in a single, logical step, such as the addition of two numbers. Compound operations are those that require a series of multiple atomic operations.

A compound statement, in classic procedural or object-oriented programming, can lose its structure once it is compiled. The reflective programming paradigm introduces the concept of meta-information, which keeps knowledge of program structure. Meta-information stores information such as the name of the contained methods, the name of the class, the name of parent classes, and/or what the compound statement is supposed to do. Using this stored information, as an object is consumed (processed), it can be reflected upon to find out the operations that it supports. The operation that issues in the required state via the desired state transition can be chosen at run-time without hard-coding it.

Uses

Reflection can be used for observing and/or modifying program execution at runtime. A reflection-oriented program component can monitor the execution of an enclosure of code and can modify itself according to a desired goal related to that enclosure. This is typically accomplished by dynamically assigning program code at runtime.

Reflection can also be used to adapt a given program to different situations dynamically. For example, consider an application that uses two different classes X and Y interchangeably to perform similar operations. Without reflection-oriented programming, the application might be hard-coded to call method names of class X and class Y. However, using the reflection-oriented programming paradigm, the application could be designed and written to utilize reflection in order to invoke methods in classes X and Y without hard-coding method names. Reflection-oriented programming almost always requires additional knowledge, framework, relational mapping, and object relevance in order to take advantage of more generic code execution. Hard-coding can be avoided to the extent that reflection-oriented programming is used.

Implementation

A language supporting reflection provides a number of features available at runtime that would otherwise be very obscure or impossible to accomplish in a lower-level language. Some of these features are the abilities to:

These features can be implemented in different ways. In MOO, reflection forms a natural part of everyday programming idiom. When verbs (methods) are called, various variables such as verb (the name of the verb being called) and this (the object on which the verb is called) are populated to give the context of the call. Security is typically managed by accessing the caller stack programmatically: Since callers() is a list of the methods by which the current verb was eventually called, performing tests on callers()[1] (the command invoked by the original user) allows the verb to protect itself against unauthorised use.

Compiled languages rely on their runtime system to provide information about the source code. A compiled Objective-C executable, for example, records the names of all methods in a block of the executable, providing a table to correspond these with the underlying methods (or selectors for these methods) compiled into the program. In a compiled language that supports runtime creation of functions, such as Common Lisp, the runtime environment must include a compiler or an interpreter.

Reflection can be implemented for languages not having built-in reflection facilities by using a program transformation system to define automated source code changes..

Examples

//Without reflection
Foo foo = new Foo();
foo.Hello();
 
//With reflection
Type t = Assembly.GetCallingAssembly().GetType("FooNamespace.Foo");
t.InvokeMember("Hello", BindingFlags.InvokeMethod, null, Activator.CreateInstance(t), null);

This next example demonstrates the use of advanced features of reflection. It loads an assembly (which can be thought of as a class library) dynamically and uses reflection to find the methods that take no parameters and figure out whether it was recently modified or not. To decide whether a method was recently modified or not, it uses a custom attribute RecentlyModified which the developer tags the methods with. Presence of the attribute indicates it was recently modified. An attribute is itself implemented as a class, that derives from the Attribute class.

The program loads the assembly dynamically at runtime, and checks that the assembly supports the RecentlyModified attribute. This check is facilitated by using another custom attribute on the entire assembly: SupportsRecentlyModified. If it is supported, names of all the methods are then retrieved. For each method, objects representing all its parameters as well as the objects representing the RecentlyAttribute are retrieved. If the attribute retrieval succeeds and the parameter retrieval fails (indicating presence of the attribute but absence of any parameters), a match has been found.

//RecentlyModified: Applicable only to methods. 
//SupportsRecentlyModified: Applicable to the entire assembly.
 
[AttributeUsage(AttributeTargets.Method, AllowMultiple=false)]
class RecentlyModifiedAttribute : Attribute
{
    public RecentlyModifiedAttribute() { }
}
 
[AttributeUsage(AttributeTargets.Assembly, AllowMultiple=false)]
class SupportsRecentlyModifiedAttribute : Attribute
{
    public SupportsRecentlyModifiedAttribute() { }
}

static void Main(string[] args)
{
    //Load the assembly dynamically and make sure it supports the Recently Modified Attribute
    Assembly loadedAssembly = Assembly.LoadAssembly(Console.ReadLine());
    if (Attribute.GetCustomAttribute(
           loadedAssembly, typeof(SupportsRecentlyModifiedAttribute)) != null)
        //For each class in the assembly, get all the methods. Iterate through the methods
        //and find the ones that have both the RecentlyModified attribute set as well as do
        //not require any arguments.
        foreach (Type t in loadedAssembly.GetTypes())
        {
            if (t.IsClass)
                foreach (MethodInfo method in t.GetMethods())
                {
                    //Try to retrieve the RecentlyModified attribute
                    object[] rmAttribute = method.GetCustomAttributes(
                        typeof(RecentlyModifiedAttribute), false);
 
                    //Try to retrieve the parameters
                    ParameterInfo[] parames = method.GetParameters();
                    if (rmAttribute.Length == 1 && parames.Length == 0)
                        Console.WriteLine("{0}", method.Name);
                }
        }
}

C++

Although the language itself does not provide any support for reflection, there are some attempts based on templates, RTTI information, using debug information provided by the compiler, or even patching the GNU compiler to provide extra information.

Common Lisp

;;Without reflection
(hello)
 
;;With reflection
(funcall (read-from-string "hello"))
 
;;or
(funcall (symbol-function (intern "hello")))

However, this works only for symbols in topmost lexical environment (or dynamic one). A better example, using CLOS, is:

;;Method hello is called on instance of class foo.
(hello (make-instance 'foo))
 
;;or
(hello (make-instance (find-class 'foo))

This code is equivalent to Java's one. Common Lisp, like Scheme, is able to transform lists into functions or procedures. This is the source of the Lisp macro ability to change the code behavior (including from other macros) during (and after) compilation.

ECMAScript (JavaScript)

// Without reflection
new Foo().hello()
 
// With reflection
 
// assuming that Foo resides in this
new this['Foo']()['hello']()
 
// or without assumption
new (eval('Foo'))()['hello']()

Java

// Without reflection
Foo foo = new Foo();
foo.hello();
 
// With reflection
Class cls = Class.forName("Foo");
Object foo = cls.newInstance();
Method method = cls.getMethod("hello", null);
method.invoke(foo, null);

Both code fragments create an instance of a class Foo and call its hello() method. The difference is that, in the first fragment, the names of the class and method are hard-coded; it is not possible to use a class of another name. In the second fragment, the names of the class and method can easily be made to vary at runtime. The downside is that the second version is harder to read, and is not protected by compile-time syntax and semantic checking. For example, if no class Foo exists, an error will be generated at compile time for the first version. The equivalent error will only be generated at run time for the second version.

Perl

# without reflection
my $foo = Foo->new();
$foo->hello();
 
# with reflection
my $class  = "Foo";
my $method = "hello";
my $object = $class->new();
$object->$method();

PHP

Using reflection the class and method are retrieved as reflection objects and then used to create a new instance and invoke the method.

Python

Here is an equivalent example from the Python shell. Reflection is an important part of Python and there are several ways it can be achieved, many of which do not include the use of the eval() function and its attendant security risks:

>>> # Class definition
>>> class Foo(object):
...     def Hello(self):
...         print "Hi"
... 
>>> # Instantiation
>>> foo = Foo()
>>> # Normal call
>>> foo.Hello()
Hi
>>> # Evaluate a string in the context of the global namespace
>>> eval("foo.Hello()", globals())
Hi
>>> # Interpret distinct instance & method names from strings
>>> instancename = 'foo'
>>> methodname = 'Hello'
>>> instance = globals()[instancename]
>>> method = getattr(instance , methodname)
>>> method()
Hi
>>> # or get a method from class not from object
>>> classfoo = type(instance)       
>>> unboundmethod= getattr(classfoo , methodname)
>>> unboundmethod(instance)
Hi

Ruby

Smalltalk

The class name and the method name will often be stored in variables and in practice runtime checks need to be made to ensure that it is safe to perform the operations:

"With reflection"
 
| x y className methodName |
 
className := 'Foo'.
methodName := 'hello'.
 
x := (Compiler evaluate: className).
 
(x isKindOf: Class) ifTrue: [
    y := x new.
 
    (y respondsTo: methodName asSymbol) ifTrue: [
        y perform: methodName asSymbol
    ]
]

Smalltalk also makes use of blocks of compiled code that are passed around as objects. This means that generalised frameworks can be given variations in behavior for them to execute. Blocks allow delayed and conditional execution. They can be parameterised. (Blocks are implemented by the class BlockClosure).

X := [ :op | 99 perform: op with: 1].
   ".....then later we can execute either of:"
X value: #+   "which gives 100, or"
X value: #-   "which gives 98."

Reflection (computer science)

Contents