Re: Name That Class

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

     2) Inheritance lists would be no problem, since supers must be of
     the same metaclass anyway.
That's not true, supers can be of other compatible metaclasses.
     
     
     But, as Patrick has pointed out, the issue is more complex. The name
     to class (or name to generic function) binding has an additional component,
     namely the environment. What I think we *really* want is a way to have
     the name to object binding be dependent on the environment as well.
     This issue is more important than the issue of user level multiple
     names per class (even for metaclass programming) since it directly
     affects implementations which can't use virtual memory to segment
     processing steps, and could adversely affect bootstrapping in any event.
     As I mentioned in a previous note, I think this issue should be resolved
     by a comprehensive, well thought out statement about the processing model
     for the Concepts chapter. Then, individual functions which require
     interface modifications should be modified. As Patrick mentioned in his
     note, the environment need not be a CLtL environment; in fact, given
     the second class status of environments in Common Lisp, it is hard
     to see how it *could* be without some beefing up of what you can do
     with them.

This is an entirely different issue from what you've been talking about.
Environments and metaclasses are orthogonal.
     
     I'll leave it at that for this note. Summarizing, my feeling is that
     allowing a multiple name per class object binding has some serious problems
     for user level code, since the names of class objects are and
     probably should be settable. I don't feel offering the functionality
     to users is particularly important at this time, but if people want
     it, then I think restricting the name to object mapping to be one to
     one on a metaclass by metaclass basis is probably the right way to go.

I don't see what can be gained by having one namespace per metaclass.  I think
it compromises modularity.  When you list your supers in DEFCLASS, you
don't/shouldn't have to care what metaclass they belong to as long as they are
compatible with your metaclass.

Patrick.