REFLECTION (COMPUTER SCIENCE)

In computer science, 'reflection' is the process by which a computer program of the appropriate type can be modified in the process of being executed, in a manner that depends on abstract features of its code and its runtime behavior. Figuratively speaking, it is then said that the program has the ability to "observe" and possibly to modify its own structure and behavior. The programming paradigm driven by reflection is called ''reflective programming''.
Typically, reflection refers to runtime or dynamic reflection, though some programming languages support compile time or static reflection. It is most common in high-level virtual machine programming languages like Smalltalk, and less common in lower-level programming languages like C.
At the lowest level, machine code can be treated reflectively because the distinction between instruction and data becomes just a matter of how the information is treated by the computer. Normally, 'instructions' are 'executed' and 'data' are 'processed', however, the program can also treat instructions as data and therefore make reflective modifications.
With higher level languages, when program source code is compiled, information about the structure of the program is normally lost as lower level code (typically machine language code) is produced. If a system supports reflection, the structure is preserved as metadata with the emitted code.
In languages that do not make a distinction between runtime and compile-time (Lisp, Forth and MUMPS, for example), there is no difference between compilation or interpretation of code and reflection.

Contents

Reflective paradigm

Uses of reflection

Implementation

Examples

Java

PHP

Perl

Ruby

Windows PowerShell

MOO

Python

Objective-C

C++

ActionScript

LISP

Scheme

Io

Smalltalk

C#

See also

References

External links

Further reading

Reflective paradigm

Reflective programming is a programming paradigm, used as an extension to the object-oriented programming paradigm, to add self-optimization to application programs, and to improve their flexibility. In this paradigm, computation is equated not with a program but with execution of a program. Other imperative approaches, such as procedural or object-oriented paradigm, specify that there is a pre-determined sequence of operations (function or method calls), that modify any data or object they are given. In contrast, the reflective paradigm states that the sequence of operations won't be decided at compile time, rather the flow of sequence will be decided dynamically, based on the data that need to be operated upon, and what operation needs to be performed. The program will only code the sequence of how to identify the data and how to decide which operation to perform.
Any computation can be classified as either of two:

★ Atomic - The operation completes in a single logical step, such as addition of two numbers.

★ Compound - Defined as a sequence of multiple atomic operations.
A compound statement, in classic procedural or object-oriented programming, loses its structure once it is compiled. The reflective paradigm introduces the concept of ''meta-information'', which keeps knowledge of this structure. Meta-information stores information such as the name of the contained methods, name of the class, name of parent classes, or even what the compound statement is supposed to do. This is achieved by keeping information of the change of states that the statement causes the data to go through. So, when a datum (object) is encountered, it can be reflected to find out the operations that it supports, and the one that causes the required state transition can be chosen at run-time, without the need to specify it in code.

Uses of reflection

Reflection can be used for self-optimization or self-modification of a program. A reflective sub-component of a program will monitor the execution of a program and will optimize or modify itself according to the function the program is solving. This is done by modifying the program's own memory area, where the code is stored.
Reflection can also be used to adapt a given system dynamically to different situations. Consider, for example, an application that uses some class X to communicate with some service. Now suppose it needed to communicate with a different service, via a different class Y, which has different method names. If the method names were hard coded into the application, it would need to be rewritten, but if it used reflection this could be avoided. Using reflection, the application would have a knowledge about the methods in class X. And class X could be designed to provide information regarding which method is being used for what purpose. The application, depending on what it has to do, would select the required method and use it. Now, when the different service is being used, via class Y, the application would search the methods in the new class to find the required methods and use them. No modification of the code is necessary. Even the class name need not be hard coded, rather it can be stored in a configuration file, it will be correctly searched for and loaded at run time.

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:

★ Discover and modify source code constructions (such as code blocks, classes, methods, protocols, etc.) as a first-class object at runtime.

★ Convert a string matching the symbolic name of a class or function into a reference to or invocation of that class or function.

★ Evaluate a string as if it were a source code statement at runtime.
These features can be implemented in different ways. Interpreted programming languages, such as Ruby and PHP, are ideally suited to reflection, since their source code is never lost in the process of translation to machine language—the interpreter has the source readily available.
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

Java

The following is an example in Java using the Java package . Consider two pieces of code

// Without reflection
Foo foo = new Foo();
foo.hello();
// With reflection
Class cls = Class.forName("Foo");
Method method = cls.getMethod("hello", null);
method.invoke(cls.newInstance(), 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.

PHP

Here is an equivalent example in PHP:

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

Perl

Here is an equivalent example in Perl:
# without reflection
my $foo = Foo->new();
$foo->hello();
# with reflection
my $class = "Foo";
my $method = "hello";
my $object = $class->new();
$object->$method();

Ruby

Here is an equivalent example in Ruby:
# without reflection
Foo.new.hello
# with reflection
Class.const_get("Foo").new.send(:hello)

Windows PowerShell

Here is an equivalent example in Windows PowerShell:
# without reflection
$foo = new-object Foo
$foo.hello()
# with reflection
$class = 'Foo'
$method = 'hello'
$object = new-object $class
$object.$method.Invoke()

MOO

Here is an equivalent example in MOO:
"without reflection";
foo:hello();
"with partial reflection";
foo:("hello")();

Python

Here is an equivalent example in Python:

# without reflection
Foo().hello()
# with reflection
getattr(globals()['Foo'](), 'hello')()

Objective-C

Here is an equivalent example in Objective-C (using Cocoa runtime):
// Without reflection