Re: ENSURE-CLASS-USING-CLASS

[David N Gray <Gray@DSG.csc.ti.com>]

>    Therefore, I believe that the present model is not general enough and a
>    :NAME argument needs to be added to the class initialization arguments.
>
> I don't think you are prevented from adding your own initargs to make-instance
> for metaobjects. Adding :name to the make-instance call that comes from the
> expansion of a defflavor is a fine extension. The other issue is to require
> that the call to make-instance resulting from the expansion of defclass
> contains the :name argument. Do you really want that? It does not seem
> absolutely necessary. 

Yes, I want it.  (It turns out that the :ENVIRONMENT argument also needs
to be passed along with the name.)  If it is intended that the
:METACLASS option of DEFCLASS will only be used with subclasses of
STANDARD-CLASS, then it would not be necessary, but that seems like an
unnecessary restriction on the extensibility of DEFCLASS.  The same
problems can arise if you want to do (:METACLASS STRUCTURE-CLASS).  This
isn't just a theoretical problem; we already have people using DEFCLASS
to define windows and conditions, which in the current Explorer
implementation are actually implemented as flavors.  That worked quite
nicely when we were using ADD-NAMED-CLASS, but when I converted to using
the ENSURE-CLASS model, I found that I needed to either add the name and
environment to the initialization arguments or else use the clumsy
approach of passing them under the table in special variables.

To turn the question around, is there some advantage to hiding the
name from the initialization code?