Re: Metaclass Protocol Goals

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

     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:

Thank you for your comments.
     
     >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.

What I meant is that the metaclass does affect the way classes parse their
defclass, compute class precedence list, gather their slots... all these things
are class business. On the other hand, it affects how instances are allocated,
laid out, accessed. That's instance business. These two sorts of businesses are
independent. I may want to keep a CLOS Syntax, CPL, etc, but have my instances
represented differently. I may want to define a FLAVOR metaclass and
represent its instances the way the default CLOS metaclass represents them.

					
     >- The side effects on CLOS objects (Classes, generic-functions, methods)
     >that spread 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.

Exposed means documented (what it is), with a protocol that goes with it (what
you can do, how you do it).

"Side effects on CLOS objects that spread across object links" means the side
effects that affect some other objects, not just the one you intended to
side-effect.  For example, if you redefine a class, you are likely to affect
other classes besides the one you are redefining.  These side effects are
particularly important to specify because they can spread across metaclasses.
If metaclass A handles class redefinition one way and metaclass B handles it in
a different way, then clearly we have a problem if we can mix classes of A with
classes of B.
     
     >- 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 define a protocol, not a language.  A protocol is a set of rules that someone
must observe in order to preserve the integrity of the system.  If we say "This
should be side effect free", it means that someone writing a new metaclass must
satisfy this constraint if he expect CLOS to continue working right.  We
certainly don't want to do anything complicated to enforce it.
     
     >- 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).

What I was trying to say here is we must define provision for implementations to
do a good job of defining a compilation environment, not to require it.

     
      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.

Running into problems because the implementation does not allow you to do it is
one thing, running into problems because the metaclass protocol makes it
impossible is another thing.

Patrick.