CLIM mail archive
[Prev][Next][Index][Thread]

define-application-frame superclasses

    Date: Thu, 23 May 1991 09:35 EDT
    From: Mark Nahabedian <naha@yukon.scrc.symbolics.com>

	Date: Wed, 22 May 1991 21:24 EDT
	From: kanderso@BBN.COM


	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
	i expected:

	(defclass application-frame (generic-frame frame)
	 ...)

	I think this is a bug.  Is it a bug or a feature?

	k

    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.

0,,
References:
Main Index | Thread Index