CLIM mail archive
Date: Thu, 23 May 1991 09:35 EDT
From: Mark Nahabedian <firstname.lastname@example.org>
Date: Wed, 22 May 1991 21:24 EDT
In CLIM 0.9.68, CLX 4.4, Lucid 4.0.2.
I basically wanted to build an application frame out of a more generic
application independent frame. I tried something like:
(define-application-frame generic-frame ()
(define-application-frame application-frame (generic-frame)
to my suprise, this macro generates a class like:
(defclass application-frame (frame generic-frame)
which leads to a unlinearizable class-precedence list, rather than what
(defclass application-frame (generic-frame frame)
I think this is a bug. Is it a bug or a feature?
Can't you just define GENERIC-FRAME using DEFCLASS instead of
DEFINE-APPLICATION-FRAME? Is GENERIC-FRAME just a straight mixin or does
it depend on CLIM:APPLICATION-FRAME? One thing to be careful of is that
when you specify superclasses in define-application-frame, you must
include CLIM:APPLICATION-FRAME explicitly. This is so that you can have
control over precedence ordering. All this is for 1.0, I'm not sure how
dissimilar 0.9 is?
For all you CLIM 1.0 users: as Naha says, in CLIM 1.0, only those
superclasses explicitly listed in the DEFINE-APPLICATION-FRAME are used as
the superclasses of the new class. If you didn't supply any superclasses,
the default is CLIM:APPLICATION-FRAME. Thus, having one frame inherit from
another "just does the right thing", but if you want to inherit from some
classes that *weren't* defined using DEFINE-APPLICATION-FRAME, you will
need to explicitly include CLIM:APPLICATION-FRAME in the superclasses.
I see that DCPL has already answered the question for CLIM 0.9.
Main Index |