Metaclass Protocol

[Patrick H Dussud <DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET>]

This message is a first-cut attempt at a design rationale for the
metaclass protocol.  The metaclass protocol being quite large, it will
be easier if we discuss and agree on the design rationale first.


We want to standardize the metaclass protocol to meet these objectives:

- Allow for portable compatible extensions to the CLOS model.  
1)Some might change the instances representation/behavior while
retaining a compatible top-level interface; Persistent objects systems
and Distributed objects systems are some examples.
2)Some might extend the model by changing the classes behavior like
Delegation instead of Inheritance or they can implement another object
system for backward compatibility reasons (like Flavors, Common
Objects...).  It would be desirable to allow a certain degree of
coexistence between classes belonging to different metaclasses.


- Allow for generic high level tools(Inspectors, generators, analyzers).
As a number of extensions will become available, there will be a need
for a single set of tools able to deal equally well with those
extensions. 


Requirements:

The metaclass protocol should allow the implementation to pick the best
optimization strategy (in terms of code generation and instance
representation).

The metaclass protocol should allow for any programming development
styles.  The idea is that an implementation should be able to support
both smooth incremental development and efficient wholesale file
compilation.

The metaclass protocol should support first class objects and anonymous
generic functions.


- Class behavior and instance behavior are othorgonal in CLOS.  The
metaclass protocol must preserve this orthoganality.  The metaclass
protocol should be as modular as possible.  I would want to be able to
write a Persistent-mixin metaclass and then mix it with STANDARD-CLASS
to get a persistent standard-class or with FLAVORS to get a persistent
flavors metaclass, instead of having to implement a full-blown metaclass
for every case.

I think those objectives and requirements open up some specific issues:

- The side effects on CLOS objects (Classes, generic-functions, methods)
that spead across object links should be exposed.
Compute-class-precedence-list is a good example.

- It should be possible to access some exposed slots of a CLOS object
without side-effect.  An inspector may need to access the
Class-precedence-list slot of a class without triggering
compute-class-precedence-list on the class.  I think that means we need
to have a way to indicate when a slot contains valid data.

- We probably need to care about the compile environment.  We don't have
to specify what it is but where, in our protocol it should be looked up
or side effected.  At least we must make sure that we don't go against
the following statements:
1)Compile-file does not side effect the running environment.
2)It is possible to implement a cross loader (Something that loads files
in order to make some class definitions, etc  that will affect 
the compilation but not the running environment).


The list of requirement and issues is far from being complete, but it
probably covers enough  to get the discussion started.

Patrick.