Opaque objects and introspection

From: Ken Anderson <KAnderson_at_BBN.COM>
Date: Fri, 12 May 95 12:52:34 -0400

I had several questions about the intent of stklos in several areas:

Q1. Opaqueness. The original Tiny CLOS metaobjects were unnamed. This
made debugging hard. Stklos metaobjects are named but print themselves
by only showing their class and their address. This makes things like a
class' class-precedence-list, or a methods list of specializers fairly
uninformative. If the intent is for STklos metaobjects to be named, then
it would be more informative if these objects printed their names.

Q2. Method names. <method>'s have a name slot, but it is currently
unbound. What is the intent of this slot. Should it be the name of the
generic function? It looks like the method macro has a bug in it, and
(method initailize (<method>)) does not bind the name slot.

Q3. Print-object. I'd like to propos that Stklos have a print-object
generic function as CLOS does which lets one define the print behavior of a
class. I have written print-object methods, but how should it be connected
to the I/O system.

Q4. Limits of introspection. In CLOS, i can start at the top of the class
hierarchy (the class T) and pretty much find out anything i want. This
can't be done in STklos. For example, in CLOS given a class, i can find
all methods specialized on this class. In STklos, i can't. Is this the
way it should be?

k
Received on Fri May 12 1995 - 18:54:27 CEST