Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!ncar!gatech!usenet.ins.cwru.edu!tut.cis.ohio-state.edu!unreplyable!garbage
From: CORK@cs.umass.edu ("Dan Corkill, COINS, UMass 413/545-0156")
Newsgroups: comp.lang.clos
Subject: Re: Non-shared Class Allocated Slots
Message-ID: <96B8613F4EBF600D38@cs.umass.EDU>
Date: 3 Apr 91 19:21:00 GMT
Sender: welch@tut.cis.ohio-state.edu
Distribution: inet
Organization: CommonLoops
Lines: 19

Neither the macro nor the meta-object approach to creating separate,
class allocated slots for each subclass is suitable when building
modular, layered systems using CLOS/PCL.  For example, suppose I create
a class that is to be used (as a super) to created classes in other
systems/applications.  This super has special "hidden" methods and slots
that are to be inherited by subclasses created by other systems.  Both
the macro and meta-object approach violate the transparency of this
method/slot hiding from a pure class inheritance viewpoint.  Either I
have to remember to use a different defclass macro or to specify a
different metaclass when using the class as a super.  (In the GBB
generic blackboard system, we reluctantly resorted to the macro
approach...)

I strongly believe that CLOS/PCL is missing an important capability with
"class-per-class" allocated slots.  By simply providing a
:CLASS-PER-CLASS allocation specification (along with :INSTANCE and
:CLASS), transparency would be maintained without resorting to macros
and the meta-object protocol.  Implementing the extension is minor
compared to the increased functionality.