gasp@bucsd.bu.edu (Isaac Kohane) (08/26/90)
Does CLOS support sending messages to classes in the way LOOPS (on the Xerox 1108) used to (using the prototype syntax)? Otherwise, I have to create an instance to evaluate a method for that class... is that right? Thanks -Zak
gunderson@aiag.enet.dec.com (09/13/90)
>Does CLOS support sending messages to classes in the way LOOPS (on the >Xerox 1108) used to (using the prototype syntax)? Otherwise, I have to >create an instance to evaluate a method for that class... is that >right? CLOS supports computational reflection. Ordinary CLOS classes are thus instances of a metaclass. When "defclass" is used, the metaclass defaults to "standard-class". Thus, a generic function specialized on standard-class will apply to the instances of this metaclass. These instances are the classes defined with defclass. A useful terminology refers to the ordinary CLOS classes as 1st-level instances of the metaclass and the instances of an ordinary CLOS class as 2nd-level instances of the metaclass. The term "2nd level instance" was first used in Graube, Nicolas, "Metaclass Compatibility." Proceedings of the 1989 Object Oriented Programming: System Languages, and Applications Conference (OOPSLA-89), pp. 305-315, 1989. In our own work here at DEC, we extended the terminology with "1st level instance". Alan Gunderson
davis@barbes.ilog.fr (Harley Davis) (09/17/90)
In article <15344@shlump.nac.dec.com> gunderson@aiag.enet.dec.com writes:
A useful terminology
refers to the ordinary CLOS classes as 1st-level instances of the metaclass
and the instances of an ordinary CLOS class as 2nd-level instances of
the metaclass. The term "2nd level instance" was first used in
Graube, Nicolas, "Metaclass Compatibility." Proceedings of the 1989 Object
Oriented Programming: System Languages, and Applications Conference
(OOPSLA-89), pp. 305-315, 1989.
In our own work here at DEC, we extended the terminology
with "1st level instance".
Alan Gunderson
I happen to think this isn't such great terminology, largely because
the word "level" is somewhat too general for such a specific use. I
prefer the term "metainstance" for what Nicolas (and you) call "2nd
level instance", because it is a unique term, and it complements the
term "metaclass". An object's metaclass is the class of its class; an
object's metainstances are the instances of its instances.
-- Harley
--
------------------------------------------------------------------------------
Harley Davis internet: davis@ilog.fr
ILOG S.A. uucp: ..!mcvax!inria!davis
2 Avenue Gallie'ni, BP 85 tel: (33 1) 46 63 66 66
94253 Gentilly Cedex
Francegregor@think.com (Gregor Kiczales) (09/18/90)
From: davis@barbes.ilog.fr (Harley Davis)
Newsgroups: comp.lang.lisp
Subject: Re: Prototype methods in CLOS?
I happen to think this isn't such great terminology, largely because
the word "level" is somewhat too general for such a specific use. I
prefer the term "metainstance" for what Nicolas (and you) call "2nd
level instance", because it is a unique term, and it complements the
term "metaclass". An object's metaclass is the class of its class; an
object's metainstances are the instances of its instances.
One problem with the term "metainstance" is that it is appealing to use
it to refer to the data representation of instances imposed by the
"metaclass".
Suppose that a given "metaclass" wants the instances of its instances to
be respresented as tagged, 2 word structures, with all the slots in an
alist, and supporting finalization. (You can't do this in portable CLOS,
but you could imagine doing it with the MOP in an implementation-specific
way, or with a more agressively MOPed language.)
It is convenient to have a name for that naked storage format, that is
the tagged 2 word structure, and also convenient to have a name for
"instances" of that naked storage format. "metatype" and "metainstance"
are two possible names for these.
One the other hand, my personal belief is that CLOS and MOPs of its ilk
should stop using the term "metaclass" and instead use the term "class
metaobject class." This new term is more precise, and avoids confusion
with the much broader power associated with the term "metaclasses" by
later languages such as 3-KRS.