[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Environments, Naming, and CLOS (was Re: Name that Class)
- To: Patrick H Dussud <DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET>
- Subject: Environments, Naming, and CLOS (was Re: Name that Class)
- From: kempf%hplabsz@hplabs.HP.COM
- Date: Mon, 17 Aug 87 18:02:50 MST
- Cc: common-lisp-object-system@SAIL.STANFORD.EDU
- In-reply-to: Your message of Thu, 13 Aug 87 10:25:05 -0500. <2764855505-13956774@Jenner>
> 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.
I stand corrected. In the event of a name clash, some means
of disambiguating the name to class mapping would be needed.
One possiblility would be to extend the definition of "compatible"
to include "not having classes with the same name". Provided,
of course, that multiply named classes were seen to be such
an important feature that they should be included (which I
> 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 is an entirely different issue from what you've been talking about.
> Environments and metaclasses are orthogonal.
To the extent that the metaclass protocol takes into account
the processing environment, it may be possible for a particular
metaclass to do things differently in an environment from
others. For example, a metaclass supporting a language which
always resolves inheritance at compile time would need to
deal with the environment in a different way from the default
metaclass, where inheritance is resolved much later.
> 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 thin> k>
> 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.
I agree. I can't see much use for allowing multiple names for
classes in the first place, since it requires more syntatic
machinery on the part of the programmer to indicate precisely
which class is meant in user level code. The point of the
metaclass proposal was that, if anywhere, that might be a
place where people might want to have multiple classes with
the same name. Suppose, for example, you want to have a
WINDOW class in CLOS and one in Smalltalk (or CommonObjects,
or Flavors, etc.). But Common Lisp provides packages for
seperating namespaces, and I think that's probably enough, as
long as you don't insist on exporting more than one WINDOW.
So you could have a FLAVORS::WINDOW and a SMALLTALK::WINDOW.
Personally, I think that this issue (multiple names for classes)
is a bit of a red herring. I just presented the metclass proposal
as an example of how it might make sense, but, as was pointed
out, additional machinery would be required at the syntatic
level to support it. The package system, despite its faults,
is the customary way of modularizing namespaces in Common Lisp,
and I think we should stick with that for user level code.
The issue of multiple names in different processing environments
is somewhat different. Because the package system is read time
only, and symbols map across compilation and loading into the
same package, the package system cannot be used to allow a
class of the same name to co-exist at compile time. Similarly
for methods. In order for a class or a set of classes and
their applicable methods to be compilable in the same file,
the CLOS metaclass protocol must insert enough information
into the compile time environment so that the methods can
be defined. At the extreme, the classes being compiled
could be simply be completely defined at compile time, but
this will, of course trash any existing definitions. This is
not a problem for implementations which an easily get new
virtual address spaces (modulo lengthening the time required
for compilation of a system), since most bootstrapping problems
could be solved by simply throwing away the environment and
getting a new one (there are probably some more subtle problems
here which I'm missing).
Is that a fair statement of the problem with environments
As mentioned in previous notes, I think a section in Part I
about what CLOS needs in terms of processing environment
is important. I might add that the ANSI C standard has
about 8 pages of material on the processing environment at
the beginning. We are, of course, limited by what CLtL provides,
but I think, within that limit, we can probably be more