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

Presentation typep and subtypep

    Date: Wed, 28 Oct 1992 14:49 EST
    From: Brian Anderson <bha@atc.boeing.com>


    > Date: Tue, 27 Oct 1992 19:41-0500
    > From: Scott McKay <SWM@STONY-BROOK.SCRC.Symbolics.COM>
    > 
    >     Date: Tue, 27 Oct 1992 16:21 EST
    >     From: Brian Anderson <bha@atc.boeing.com>
    > 
    >     Allegro CL 4.1
    >     CLIM 1.1
    >     SunOS 4.1.1
    > 
    >     I am perplexed by the behavior of presentation-typep and
    >     presentation-subtypep.  I guess that I just don't have a clear model
    >     for what is going on.  I have not been able to glean one for the
    >     documentation either.  I (and I'll bet others) would benefit from a
    >     clear description of the model.

    Note, that my confusion can be (almost) entirely explained by the bug
    in the identity translator and the apparent bizare behavior that I was
    seeing as a result.  The patch you sent fixes one of my problems and
    the university example now works.  Thanks.  Please note that towards
    the end of this posting, I think I have identified another bug.

    Hmmm, is there a set of patches for CLIM 1.1 around?  I spent 3 days
    on this.  While I learned alot, not all of that time was used wisely.
    How many other "patches" might there be laying around?

Not many patches lying around.  I think that may be one of the few of
very broad interest.  I also think I have posted it before on this
mailing list, but I'm not sure.

    Franz - what about this?

    > First note that p. 366 is only talking about when PRESENTATION-TYPEP
    > presentation methods get called, *not* when the function
    > PRESENTATION-TYPEP is called.  It is true that the function
    > PRESENTATION-TYPEP gets called when you wave the mouse around, but this
    > is not guarantee that your PRESENTATION-TYPEP presentation methods will
    > get called.  In fact, CLIM tries hard not to call those methods when you
    > are just waving the mouse around.
    > 
    > The same goes for PRESENTATION-SUBTYPEP.

    Yes.  Note that the discussion really seems to be saying how
    translators use presentation-typep and presentation-subtypep (?).
    I suppose other parts of CLIM use these methods also?

As it turns out, only the callers withing CLIM of PRESENTATION-TYPEP and
PRESENTATION-SUBTYPEP are in things directly related to translator
searching and closely related things, but that is really only an
artifact of the functionality CLIM provides.

    > CLIM did not bother calling your PRESENTATION-TYPEP method in the first
    > case because all CLOS objects are Lisp expressions, always.  None of
    > your type parameters can change this.

    Eh?  You mean for the clim:expression presentation type or my
    presentation type based upon a CLOS name?

Your p-type based on a CLOS name (I think :-).

    > You might be better served by calling PRESENTATION-TYPEP directly rather
    > than relying on waving your mouse over objects in some window.  This is
    > also confusing you.  As I said above, CLIM tries very hard to avoid
    > calling *any* user code when you are waving the mouse around; it does
    > this in order to be as fast as possible.

    Yes.  But it really helps to know how these things are going to be
    called by CLIM.  And considering the unexplainable behavior induced by
    the bug in the identity translator, it really threw me off.

I can believe that.

    >     So, is the presentation-typep method supposed to say whether an object
    >     "has a" presentation of some type or is it to determine if the current
    >     input context applies with respect to the application object?  Why is
    >     this method not called in certain cases for CLOS classes?
    > 
    > PRESENTATION-TYPEP simply answers the question "is such-and-such object
    > of the specified (presentation) type".  For presentation types that are
    > the same as a CLOS class (with no parameters), PRESENTATION-TYPEP is
    > identical to TYPEP.  When you add parameters, you yourself must specify
    > how this affects type inclusion.  The same goes for p-types that are not
    > CLOS classes - you must specify what objects are in the class.

    OK.  Its additionaly interesting to note that first CLIM tries to see
    if two presentation type specifiers match (using
    presentation-subtypep), and if it cannot determine a match from this
    it calls presentation-typep to see if we can determine a match by
    looking at the object.  The patch you sent is interesting in this
    regard.  It gives us a clue to how things are working behind the
    scenes.  Also, the discussion on pg. 192 helps.  If we write
    translators for parameterized presentation types, then I suppose we
    should follow the same methodology???

You can probably just get away with calling PRESENTATION-TYPEP.

    >     If this invisible behavior is by design (and my analysis is correct),
    >     I question whether this is the most appropriate and consistent
    >     abstraction.  It would be less confusing if there wasn't this
    >     "invisible" behavior for CLOS classes.  If there is a default for
    >     presentation types whose name is the same as a CLOS class - OK, thats
    >     cool.  If I define a presentation-typep method, it should *override*
    >     this default presentation-typep method.  
    > 
    > I disagree.  You would then be saying that there are two types having
    > the same name that have different behavior.  This seems crazy, and would
    > simply promote bugs.

    OK.  To reword, for CLOS classes we can infer from the name of a class
    and the name of a presentation type whether there is a match (via
    typep).  This can be done at a higher level than presentation-typep.

Yes.

    Then, presentation-subtypep is responsible for determining
    subtype-ness of parameterized presentation type specifiers and
    presentation-typep is responsible for determining presentation type
    matching against the application object (a CLOS instance) only when
    there are presentation type parameters.

Yes, exactly.

    >     So, lets continue on to presentation-subtypep.  My
    >     presentation-subtypep method is always called whether I mouse over a
    >     meta presentation of a presentation of the type that the
    > 
    > I wouldn't know a "meta presentation" if I fell on one.

    I meant clim:expression, clim:member-alist, etc.

OK.

    > Please, just call PRESENTATION-SUBTYPEP directly, and leave ACCEPT and
    > WITH-INPUT-CONTEXT out of it.  Things will look much clearer.

    What do you mean?  Its exactly the behavior of things when I'm trying
    to accept stuff that is the problem.  I'm not writing a translator.
    Of course I can call these methods but what concerns me is how CLIM is
    calling them.  The fix you sent cures this problem.

OK, good.

    > You might also be getting confused by a bug in CLIM 1.1 in handler
    > matching.  Try this:
    > 
    > (in-package :clim)
    > (defun identity-translator-applicable-p (presentation context-type)
    >   (let* ((type (presentation-type presentation))
    > 	 (type-name (presentation-type-name type))
    > 	 (object (presentation-object presentation)))
    >     (with-presentation-type-decoded (context-name context-parameters) context-type
    >       (if (eq type-name 'blank-area)
    > 	  (eq context-name 'blank-area)
    > 	;; Let MENU-ITEM-IDENTITY take care of pure menu items
    > 	(unless (and (eq type-name 'menu-item)
    > 		     (eq context-name 'menu-item))
    > 	  ;; Either the types definitely match, or the types nominally match
    > 	  ;; and the object must be validated.
    > 	  (or (presentation-subtypep type context-type)
    > 	      (and (not (null context-parameters))
    > 		   (presentation-typep object context-type))))))))
    > 

    AH HA!!!!!!

    This does the trick.  This is exactly my problem.  When I load this
    patch the behavior changes to something more reasonable.  My
    presentation-typep method DOES get called for my parameterized type!!!
    Well, that eliminates alot of confusion.  The University example works
    now also.

I'm really truly sorry this bug caused you to waste so much time.

    >     Note that the same caveat is true for the bindings of presentation
    >     type parameters in the accept method!  The lexically bound names for
    >     parameters are the default values from the define-presentation-type
    >     form.  Once again, use either with-presentation-type-decoded or
    >     with-presentation-type-parameters to obtain the parameters values for
    >     the presentation type specifier passed to accept.
    > 
    > Not true, unless there is some horrible bug in CLIM under Allegro.  It
    > is certainly the case that I get the right bindings.

    Well I think there is a bug.  It has to do with inherited presentation
    types.  When I run presentation-typep using a presentation type
    specifier with parameters and whose presentation type is the name of a
    CLOS class but does not inherit, everything is OK.  But, when I run
    presentation-typep using a presentation type specifier with parameters
    and a presentation type name of a CLOS class that inherits from
    another presentation type, then all I ever get bound lexically is '*
    for parameters.

    For example:

    (defclass essential-node () ())
    (defclass basic-node (essential-node) ())

    (clim:define-presentation-type essential-node
        (&key member-of-specific-graph one-of not-one-of)
      :history t)

    (clim:define-presentation-type basic-node
	(&key member-of-specific-graph one-of not-one-of)
      :inherit-from 'essential-node
      :history t)

I defined a method that looks like this:

(clim:define-presentation-method clim:presentation-typep (object (type essential-node))
  (format t "~&~S ~S ~S" member-of-specific-graph one-of not-one-of)
  t)

    (clim:presentation-typep *my-object*
      `(essential-node :member-of-specific-graph ,*my-graph*))

    I get "member-of-specific-graph" lexically bound to *my-graph* within
    my presentation-typep method.

This works for me, too.

    (clim:presentation-typep *my-object*
      `(basic-node :member-of-specific-graph ,*my-graph*))

    I get "member-of-specific-graph" bound to '* within my (inherited)
    presentation-typep method.

I think I misspoke myself.  Inheritance is not explicit.  I apologize,
your second p-type should be written as follows:

  (clim:define-presentation-type basic-node
      (&key member-of-specific-graph one-of not-one-of)
    :inherit-from `(essential-node :member-of-specific-graph ,member-of-specific-graph
				   :one-of ,one-of :not-one-of ,not-one-of)
    :history t)

There is no explicit inheritance because parameters might be added or
removed anywhere up or down the type hierarchy, so implicit inheritance
would prevent you from being able to express what you want.  Sorry about
my confusion.

    So, do I want to turn unparameterized presents into parameterized
    presents for parameterized presentation types?  Or just let
    presentation-typep handle it?

I am pretty sure you can just let PRESENTATION-TYPEP handle it.

0,,
References:
Main Index | Thread Index