Re: Opaque objects and introspection

From: Erick Gallesio <eg_at_kaolin.unice.fr>
Date: Tue, 16 May 1995 20:13:02 +0100

> Ken Anderson writes
> 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.

This is changed now since printing can be done by two method which are called
display-object and write-object. The method Tk-write-object is even used when
an object is passed to Tk. The code of stklos.stk is now

;;; Write
(define-method write-object (o file)
  (format file "#[~S ~A]" (class-name (class-of o)) (address-of o)))

(define-method write-object((self <class>) file)
   (format file "#[~A ~A]" (class-name (class-of self))
                              (class-name self)))

;;; Display (do the same thing as write by default)
(define-method display-object (o file)
  (write-object o file))

;;; Tk-write-object is called when a STklos object is passed to a Tk-command.
;;; By default, we do the same job as write; but if an object is a <Tk-widget>
;;; we will pass it its Eid. The method for <Tk-widget> is defined elsewhere.
(define-method Tk-write-object (o file)
  (write-object o file))


Having a special method for Tk permits to customize the way informations are
passed to the toolkit. This avoids to redefine Tk-command as pack or place as
generic functions. Now when you type
        (pack b)
This will call the method which will convert b to its Eid if b is a widget. If
b is not a Tk-widget, it will convert it to #[.....] which will lead to an
error.

>
> 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.

I had not seen the problem before and I will try to correct it.

> 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.
>
See before.

> 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?
I'm not against this idea if you can tell me why this is useful.
For me, the fact to find a method starting from a class seems to go againt the
notion of generic function which are expliciteley defined outside of classes.
The only interest I see for this is for browsers.
Or is there a point I have missed?


                -- Erick
Received on Tue May 16 1995 - 20:13:03 CEST