[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


   Sender: GRAY@Kelvin.csc.ti.com
   Date: Mon, 21 Aug 89  19:16:11 CDT
   From: David N Gray <Gray@DSG.csc.ti.com>

   CLOS folks,

   I've got another problem with the Meta Object Protocol.  In 89-003, the
   description of ENSURE-CLASS-USING-CLASS and initialization of class objects
   says that the class name argument of ENSURE-CLASS-USING-CLASS is not
   passed to MAKE-INSTANCE.  An anonymous class object is created, and then
   give it a name and install it.  I had wondered why not just include a
   :NAME argument in the initialization arguments for MAKE-INSTANCE, but I
   didn't find any reason why the initialization code would have to have the
   name.  However, that's only for creating an instance of STANDARD-CLASS.
   For other metaclasses, the name may be required.

   The example that I have run into is trying to use the meta object protocol
   to define classes which are really old flavors.  The SHARED-INITIALIZE
   method is supposed to install the new class in the class hierarchy, but
   since old flavors has no concept of anonymous flavors, it is impossible to
   do the equivalent of ADD-DIRECT-SUBCLASS without knowing the name of the

   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. 

   Another advantage of this change is that if function
   (SETF CLASS-NAME) is not needed by ENSURE-CLASS-USING-CLASS, then a call
   to (SETF CLASS-NAME) is a change rather than an initialization, and it
   becomes possible for certain metaclasses to disallow this.  For example, I
   want to signal an error if a user tries to change the name of a flavor

It is possible to do what you want there right now. You can always leave a
name slot unbound, and have (setf class-name) check if the name was bound or
not, and signal an error if name was bound.