From: firstname.lastname@example.org (David Hopwood) Subject: Reflection (was Re: Has C++ had its day?) Organization: Oxford University, England Date: Wed, 31 May 95 02:59:04 BST
In article <email@example.com>, Ell <COATES@EUROPA.UMUC.EDU> wrote: [snip] >Curious what you mean by "reflective" design?
Reflection is the ability to change aspects of the implementation of a language (eg. method dispatch, memory allocation, synchronization policies), on a per-object (or per-class) basis.
For example, reflection can be used to add distributed message passing to a language that doesn't have this hard-wired into the compiler, simply by changing how method dispatch is implemented for remote objects.
A typical (but not the only) model of reflection has a 'meta-object' associated with each object. There is a default meta-object which defines the basic capabilities of the language (in practice, calls to this are usually inlined). The code emitted by the compiler for operations like method dispatch, etc. is modified to check whether the object in question is reflective (has a meta-object other than the default).
So, the code for a method call "receiver.method (param1, param2, ...)" might look something like:
if (receiver is non-reflective) inline code for a standard method call else m := the meta-object for receiver m.perform (receiver, method_id, parameter-list)
m can also be reflective (which leads some research papers to talk about an infinite tower of objects and corresponding meta-objects), but normally only one or two levels are used.
The meta-object can implement dispatch however it likes, for example using RPC to a distributed object, or whatever. The interface of a meta-object (which includes 'perform' in this case) is called the meta-object protocol.
Other applications of reflection include:
- memoized calls (the result of a function call is cached, for use on subsequent calls with the same parameters) - future objects (an object is calculated in a parallel thread; any access to the object blocks until it is ready) - transaction messages (as used in ODBMSs) - asynchronous messages (as used in Actor languages) - interfaces to other languages and type systems - implementation of garbage collection - heaps optimized for different granularities of object - persistence - checkpointing - replication
and so on. A good summary of reflection is
David Hopwood firstname.lastname@example.org
This document was translated by ms2html v1.8 on 01.06.95.