Re: Metaclass Protocol Goals

[Jim Kempf <kempf%hplabsz@hplabs.HP.COM>]

Patrick's design rationale looks like a good beginning, and would be a good
addition to the beginning of 87-003, as motivation for the metaclass
protocol. I had a couple of comments and questions:

>Class behavior and instance behavior are othorgonal in CLOS.  The
>metaclass protocol must preserve this orthoganality.  

I'm not quite sure I understand what you mean by class and instance
behavior being orthogoal. Since class objects are instances of
the metaclass, this statement would seem not to be true for classes
when considered as instances.

>- 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.

I'm not sure I understand what you mean by "be exposed". What I
think you mean by "side effects on CLOS objects that spread across
object links" is protocols which affect objects whose structure acts
as templates for other objects (is that so?). As an example, the
structure of a class object acts as a template for instances. If
you mean that methods affecting the structure of such "template
objects" should be included in the public metaobject protocol, then
I agree.

>- It should be possible to access some exposed slots of a CLOS object
>without side-effect. 

I agree with this, but I think it might be difficult to achieve in
practice. With method combination, it should be possible for the designer
of a metaclass to define a daemon method on any method in the protocol
which cause side effects to occur. I can think of a couple solutions to
this off the top of my head. One is to suggest that metaclass programmers
follow a convention of not defining daemon methods which cause side
effects, another is to specifically forbid defining daemon methods on 
metaclass methods, possibly through a declaration mechanism (as I
suggested in an earlier note this spring). Probably the former is better,
since daemon methods for doing things like updating browsers when 
classes are defined might be useful.

>- 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).

Given the design of the Common Lisp, this might be very 
difficult to achieve. Using the PCLOS implementation from Gregor,
I tried a quick and dirty implementation of a seperate compile time
namespace for CommonObjects on CLOS and ran into some serious problems.
Basically, for languages such as CommonObjects which compute alot of
their inheritance information at compile time, the only alternative
to side effecting the compile time environment is to somehow maintain
the information and update global structures only when its safe. This
approach is used in our native code CommonObjects implementation, and
it is expensive. The CommonObjects on CLOS compiles about twice as
fast because it just side effects the compile time environment. In the
CLOS language, if attention is not paid to side effects, then classes
need to be defined in the compile time environment so that method
definintions being defined in the same file (a logical way to organize
a body of software) can be compiled.

Aside from problems with bootstrapping CLOS itself (which Gregor
seems to pretty well have under control in the portable implementation),
much of the reason for not side effecting the compile time environment
goes away with multiple virtual address spaces. A "spoiled" compile
time environment can just be thrown away. Of course, this doesn't
solve the problem for machines where multiple virtual address spaces
are not an option.

			Jim Kempf	kempf@hplabs.hp.com