🚀 go-pugleaf

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.