Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!tut.cis.ohio-state.edu!lucid.com!jonl
From: jonl@lucid.com (Jon L White)
Newsgroups: comp.lang.clos
Subject: accessing clos objects
Message-ID: <9102151701.AA24826@kolyma>
Date: 15 Feb 91 17:01:48 GMT
References: <6096.9102151548@subnode.aiai.ed.ac.uk>
Sender: welch@tut.cis.ohio-state.edu
Distribution: inet
Organization: CommonLoops
Lines: 15

re: I think you have to establish metaclass compatibility, . . .

Well, that is only one option for a metaobject protocol; it's perfectly
reasonable NOT to have such a requirement.

In fact, Lucid's 4.0 imposes the requirement, but Symbolics' 8.1 defaults
all subclasses of STANDARD-CLASS to be mutually compatible.  I think the
intent of the current "Chapter 3" proposal is to require a positive step
by the metaclass programmer (i.e., the default is not having the enabling
method  on VALIDATE-SUPERCLASS, and the programmer must write it himself
if so wanted), and I would argue for this position.  But the other position
-- Symbolics's 8.1 choice -- isn't ruled out by "Chapters 1 & 2" alone.


-- JonL --