scc@cl.cam.ac.uk (Stephen Crawley) (09/16/89)
Paul Wilson's types-as-roles model bears more than a passing resemblance
to the type system of the distributed persistent object system that
I am working on.
Objects or *entities* are characterised 3 components; a *class* which defines
an abstract interface, an *implementation* that provides the routines etc
that implement the operations defined by the class, and the *representation*
which is understood by the implementation routines. (The separation of
interface from code in my type system allows a class to have a number of
implementations.)
Entities exist in two states. *Passive* entities have all their state in
stable store and are signified by an *identifier* or *id*. *Active*
entities may have some of their state in local (non-stable) memory and
are signified by a *handle* whose type is a class. A handle for an
entity is obtained by applying a classes *open* operation, passing the
entity id as an argument.
When a client wants to use an entity (i.e. to invoke operations), it must
have a handle for the entity. The class of the handle determines the
operations the client may invoke. This class is called the client's
*perspective class*. On the other hand the entity's *actual class* is
the class that corresponds to the entity's implementation.
Normally, the client's perspective class and the entity's actual class
are the same. If they are not, the client will invoke operations defined
by the perspective class, and these operations will be *projected* onto
operations provided by the actual class. The *projection* is set up as
the entity is opened by a piece of code called a *resolution function*.
Projections may be simple (i.e. a renaming or a restriction) or
arbitrarily complex depending on the resolution function. It was
originally intended that the mechanism be used for restricting
access to an entity's operations, and for making evolutionary
changes in a persistent type system. In practice, projection turns
out to be far more powerful mechanism. We have used it to perform
a variety of tasks ranging from displaying objects and synthesising
interactive tools through to selecting versions in a version control
system.
The current version of the entity type system does not support
static inheritance (i.e. classes don't have subclasses). It will
do, but I haven't got around to it. I'm currently concentrating
more on garbage collection and distributed programming aspects.
For further information, check out the following paper:
"Flexibility in a Persistent Object-based Type System"
H.J. Barman and S.C. Crawley in
Proceedings of the Workshop on Persistent Object Systems,
Appin Scotland, August 1987
Persistent Programming Research Report #44
University of Glasgow, Dept of C.S.
The address for U of G, CS is
University of Glasgow, Dept of Computing Science,
Lilybank Gardens,
Glasgow G12 8QQ
Great Britain.
Papers on the latest incarnation of the Entity System are in the pipeline.
-- Steve