Reflective
From Biophp.net
(diff) ←Older revision | Current revision | Newer revision→ (diff)
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' is 'processed', however, the program can also treat instructions as data and therefore make reflective modifications.
With high-level languages, when program source code is compiled, information about the structure of the program is normally lost when low-level code (typically machine language code) is produced, unless, of course, the code is compiled into an Intermediate Language (IL) which preserves that structure information. If a system supports reflection, such as by the use of an IL, then the structure is preserved as metadata with the emitted code.
Contents |
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.
Reflection is also a key strategy for metaprogramming.
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. 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..
See also
- Type introspection
- Self-modifying code
- Programming paradigms
- List of reflective programming languages and platforms
References
- Reflection-oriented programming
External links
- Reflection in logic, functional and object-oriented programming: a Short Comparative Study (Citeseer page).
- An Introduction to Reflection-Oriented Programming
- Reflection in C++/CLI for .Net
- Reflection for C++
- Aspects of Reflection in C++
- LibReflection: A reflection library for C++.
- A library to provide full reflection for C++ through template metaprogramming techniques.
- A c++ reflection-based data dictionary
Further reading
- Ira R. Forman and Nate Forman, Java Reflection in Action (2005), ISBN 193239418478e9caae14728313c1edadf9673d19db_cfcd208495d565ef66e7dff9f98764da
- Ira R. Forman and Scott Danforth, Putting Metaclasses to Work (1999), ISBN 0-201-43305-278e9caae14728313c1edadf9673d19db_cfcd208495d565ef66e7dff9f98764da
