Object-Orientation FAQ

From: lady0065@sable.ox.ac.uk (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 <3pq7eo$e50@nova.umuc.edu>, 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