multiple meta-objects (was: Meaning)

[Jecel Assumpcao Jr]

I agree with Fare' that while we can talk about each
object having a single meta-object to help illustrate
some concepts, a real system should not be quite so
simple.

Here is a page where you can find many reflective systems:

        http://web.yl.is.s.u-tokyo.ac.jp/pl/meta.html

I will mention one of them in particular, CoDA. Another
system worth examining is Apertos:

        http://www.csl.sony.co.jp/project/Apertos/index.html

Both of these system represent each object by a collection
of meta-objects. This collection is itself a real object
in Apertos (called the meta-space) and a pseudo object in
CoDA (simply called meta).

One reason to have multiple meta-objects is to allow them
to be composed together in a simple way. Imagine that we
have three "kinds" of meta-objects and there are four
varieties of each kind. We would have 4x4x4 = 64 combinations
(many of which would make no sense, of course). Each of
these combinations is obtained by plugging in the right
three meta-objects. In a system with one meta-object per
object, we would have to hand program each different case.

The other reason is state. The state needed by a meta-object
might be stored in the meta-object or in some "hidden fields"
in the base object (think of web pages - a server can store
session information locally, use hidden fields in the page or
any combination of the two). When meta-objects are not purely
functional but have local state, then it might be interesting
to share this state among many different base object. If
the meta-level is a composition of several meta-objects, this
is easy to do.

Let's look at a concrete example: CoDA. It extends Smalltalk,
which is already a somewhat reflective language. CoDA is
mostly concerned with reifying message passing. Each object
is represented by the following set of meta-objects:

    send: knows how to make this object initiate a communication
          with another one
    accept: knows what to do with incoming messages - how to deal
            with another object's send meta-object
    queue: knows what to do with messages that can't be processed
           immediately
    receive: knows how to retrieve messages from the queue
    protocol: associates messages with actual code
    execute: gets the virtual machine to actually do something
    state: provides an abstract interface to the base object's
           instance variables

By combining different implementations of these seven meta-objects,
a large number of systems were created. They include concurrent
objects, distributed objects, event driven objects, replicated
objects and so on. And an application could alway start with one
of these broad domains and then tweak one or more of these
meta-objects to get the exact message passing semantics needed.

Of these meta-objects, queue is the only one to have local state.
Having the choice of sharing this state proved very important.
One of the concurrent object implementations partitioned objects
into "groups" where only one object within a group was active
at any one time. No new code was written for this!! All that was
done is have all the objects in a group share the same queue
meta-object.

-- Jecel