[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Name That Class
- To: Jim Kempf <firstname.lastname@example.org>
- Subject: Re: Name That Class
- From: Patrick H Dussud <DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET>
- Date: Thu, 13 Aug 87 10:25:05 CDT
- Cc: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>, common-lisp-object-system@SAIL.STANFORD.EDU
- In-reply-to: Msg of Tue, 11 Aug 87 16:01:13 pdt from Jim Kempf <email@example.com>
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
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.