🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.clos
Article #699

Re: Metaclass inheritance?

#699
From: Harley Davis
Date: Mon, 11 Jan 1993 10:36
57 lines
2801 bytes
In article <1993Jan8.154239@di.epfl.ch> matomira@di.epfl.ch (Fernando Mato Mira) writes:

   Let's say you have a metaclass ATTRIBUTED-CLASS, so when you do

   (defclass foo () () 
    (:metaclass attributed-class))

   you get something like
   #<ATTRIBUTED-CLASS SCHEMA @ #x10f7f26a>

   Then somebody comes and does  
   (defclass bar (foo) ())

   and he gets
   #<STANDARD-CLASS BAR @ #x10f82c02>

   when what he really needs is
   #<ATTRIBUTED-CLASS BAR @ #x10f82c02>

   and you would like to hide the implementation-dependent metaclass.

   I think that in many cases, if you can resolve the set of common
   subclasses of the set of metaclasses of the direct superclasses of
   a class to a hierarchy, taking the root of that hierarchy as the
   default metaclass is the way that you want to go, and not getting
   just STANDARD-CLASS instead.  For disambiguating more complicated
   cases, or for getting some other metaclass than this default one,
   the :metaclass option is there.  If you do not disambiguate by
   using the :metaclass option, then getting STANDARD-CLASS as the
   default would be OK.  When a direct superclass of the class being
   defined is a forward-referenced class, it is treated by the
   previous algorithm as if its metaclass were STANDARD-CLASS instead
   of FORWARD-REFERENCED-CLASS.

   It seems that the only way of implementing this today is by
   defining an :around method on ENSURE-CLASS-USING-CLASS which is not
   exactly great to specialize, so maybe taking a look again at this
   part of the CLOS specification would be a good idea.

I think the justification for this would be to allow the compiler to
use knowledge of the metaclass at compile time to make certain
optimizations.  In practice, I'm not sure how much CLOS
implementations could use this information given other constraints,
and I'm pretty sure none currently do.

The workaround is to define your own class
definition macro for your metaclass which could be just like DEFCLASS
but inserts its own metaclass in the :METACLASS option.

-- Harley Davis
--

------------------------------------------------------------------------------
nom: Harley Davis			ILOG S.A.
net: davis@ilog.fr			2 Avenue Gallie'ni, BP 85
tel: (33 1) 46 63 66 66			94253 Gentilly Cedex, France
Technical Details
Message-ID: <DAVIS.93Jan11113652@passy.ilog.fr>
Path: arc1-ca.pugleaf.net!sparky!uunet!mcsun!julienas!corton!ilog!davis
References: <1993Jan8.154239@di.epfl.ch>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!mcsun!julienas!corton!ilog!davis
From: davis@passy.ilog.fr (Harley Davis)
Newsgroups: comp.lang.clos
Subject: Re: Metaclass inheritance?
Message-ID: <DAVIS.93Jan11113652@passy.ilog.fr>
Date: 11 Jan 93 10:36:52 GMT
References: <1993Jan8.154239@di.epfl.ch>
Sender: news@ilog.fr
Followup-To: comp.lang.clos
Organization: ILOG S.A., Gentilly, France
Lines: 57
In-reply-to: matomira@di.epfl.ch's message of 8 Jan 93 14:42:39 GMT