CLIM mail archive


Re: clos object wierdness ..

    Essentially, I'm doing the following:
    (defclass a () ())
    (defclass b () ())
    (defclass c () ())
    (defclass d (a b c) ())
    (define-presentation-type d (foo))

As far as I understood this is not a correct p-type definition
in CLIM. presentation type d MUST :inherit-from (a b c), as the
presentation-type hierarchy must always "parallel" the clos class-
    Then I have a macro which includes creating a
    subclass of d - something like
    (defmacro define-sub-d ( ... )
         (defclass ,name (d) ())
    In MCL (in NO OTHER LISP/CLIM) I get a compiler
    warning about "incompatible supertypes" between
    "d" and "presentation-type d". Then, when I run
    the macro (but not when I just do a simple defclass)
    the direct supertypes of "d" get slammed with "standard-object"
    (somewhere in the process) so that a call to define-sub-d 
    results in an "incompatible supertypes" error.

I also had this effect that a wrong p-type definition "slammed"
the clos class definition to have a superclass of "standard-object"
in lucid lisp (clim 1.1, I haven't checked it in 2.0).

I was quite angry when I discovered this effect because the clim error-message
I got when clim complained about the wrong ptype definition said nothing
about modifying my class hierarchy. (Nor is it documented anywhere...)
So it took some time to discover this effect...
    I know this is vague, but I'm having a VERY hard time
    isolating the behavior, and I'm wondering if anyone else
    has seen anything like this. This is a system I've fully
    ported to Allegro, compiled (but haven't tried to run yet)
    under Lucid, and (of course) it was developed on a Symbolics
    where it hums. So only MCL is giving me this grief.
    Any hints about where to look would be appreciated. I'm
    still working on isolating a case ...

Regards - Stefan B.

;;; - Stefan Bernemann   (

Main Index | Thread Index