Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!magnus.ircc.ohio-state.edu!tut.cis.ohio-state.edu!ZAPHOD.LANL.GOV!egdorf
From: egdorf@ZAPHOD.LANL.GOV (Skip Egdorf)
Newsgroups: comp.lang.clos
Subject: RE: accessing clos objects
Message-ID: <9102142040.AA04894@zaphod.lanl.gov.lanl.gov>
Date: 14 Feb 91 20:40:18 GMT
References: <9102141835.AA19768@cheops.cis.ohio-state.edu>
Sender: welch@tut.cis.ohio-state.edu
Distribution: inet
Organization: CommonLoops
Lines: 108


	   (defclass CLASS-WITH-INSTANCES (standard-class)
		((instances
		   :initform nil
		   :accessor class-instances)))

X3J13 88-002R Page 1-33
CLtL-II Page 800
   standard-class is specified as a pre-defined metaclass, and describes it.

	   (defmethod MAKE-INSTANCE :around ((class CLASS-WITH-INSTANCES) &rest ignore)
	     (let ((instance (call-next-method)))
	       (push instance (class-instances class))
	       instance))

X3J13 88-002R Page 1-35
CLtL-II Page 801
   make-instance described as a generic function to allow customization

X3J13 88-002R Page 1-41
CLtL-II Pages 808-809
   Shows an example definition of make-instance that seems to allow the
   example above.

X3J13 88-002R Page 2-60
CLtL-II Page 848
  (make-instance (class standard-class) ...) is shown as a primary method.
  Use of the meta-object protocol ... defining new methods specialized on
  standard-class is mentioned.

	   (defclass class-with-instances-test ()
	       ()
	     (:metaclass CLASS-WITH-INSTANCES))

X3J13 88-002R Page 2-24
CLtL-II Page 825
  :metaclass in a defclass is described.

	   (defun foo ()
	     (make-instance 'class-with-instances-test))

           ... [error descriptions] ...

           ... [Now Symbolic's response]...

   There's no need to be using a metaclass to do this kind of thing; a
   mixin with an after method on shared-initialize would do the job."

We've been beating this one to death in the last few days.
There's no need to use Lisp/CLOS for this. A Turing machine would do the job.

   We do not support metaobject protocol (a.k.a. MOP, a.k.a.  "CLOS Chapter
   3").

I don't see any Chapater 3  stuff here, Everything given in this example
uses stuff described in X3J13 88-002R Chapters 1 and 2, and CLtL-II.

True, the Draft MOP document goes into a lot more detail about specific
implementation issues, but I view this example as a part of Chapters 1 and 2,
NOT chapter 3.

   The meta-object stuff may never be adopted as is - our guess is that it
   will change a lot as part of standardization efforts because other
   implementations will want to do some things differently; in some ways
   it's still believed to be too dependent on the PCL way of doing things.

While this may be so, there are a LOT of programs being written that depend
on the CHAPTER 2 behavior used here. While I am careful enough not to depend
on some obscure function in the draft MOP, :metaclass in a defclass is well
enough defined that if one doesn't support it to the extent of this example,
then I believe that it is safe to say that that vendor does not support CLOS.

   But in any case, it will almost certainly not appear in ANSI CL, and so
   is not something you will be able to depend on in portable code, and
   we'd recommend you not get hooked on it for the practical reason of
   leaving your code open to later porting.

Allright, to this extent, there is as yet NO ANSI CL. So as long as some
splinter group wishes to oppose DEFSTRUCT or ARRAYS or something, then it
is fair to claim that "it will certainly not appear in ANSI CL" for whatever
pet ox is being gored.

With this said, I expect that defstruct, defmethod, etc from chapter 2 "WILL
almost certainly appear in ANSI CL" [note the NOT removed] in a form very
similar to what is in CLtL-II, including basic :metaclass functionality.
Remember, loop was added, not because there was such a great feeling that
loop was technically "right," but rather that there was so much bloody use of
it in existing code! I believe that the example given here falls into a similar
catagory. I can't imagine X3J13 leaving this out at this late date. All the
gory details of the draft MOP? Maybe, At least with lots of changes and
clarifications. But removing :metaclass from defclass??? I don't think so.

One can only hope that this comment only reflects a few individual opinions
within Symbolics rather than Symbolics' corporate opinion. (Such is the
usual protocol on the Net and in e-mail in general, I believe.) However,
the behavior of the Genera 8 CLOS does not give me much hope. Just as I
have given in and accepted hideous LOOP as a part of the language due to
its common usage, I hope that Symbolics will accept at least the basics of
Metaclasses as described in Chapters 1 and 2 of the CLOS spec due to their
common usage. It would be a good start to acknowledge that the Genera 8
behavior given in this example is a BUG and start taking steps to fix it.

					Skip Egdorf
					hwe@lanl.gov

Oh, Yeah. That last paragraph requires:
This is my personal opinion, and does not necessarily reflect the opinions
of the Dept. of Energy, the Univ. of Calif, or Los Alamos National Laboratory.