CLIM mail archive
[Prev][Next][Index][Thread]
Presentation typep and subtypep
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.
The following describes some problems I have had in defining a
presentation type with parameters and the presentation-typep and
presentation-subtypep methods. It also includes a description of the
behavior I have been able to glean from debugging and instrumenting my
code and my guesses as to what the underlying model could be
(sometimes confused and/or multiple guesses). I would *greatly*
appreciate any corrections to misconceptions contained herein!
This long winded posting is an attempt to clear up these problems and
misconceptions for me (and others?). I would be willing to write up
an explanation for the archive if I can obtain a good model. Maybe
someone (Scott?, Chris?) could hack this up so that it reflects
reality and mail it back to me. Then, maybe we could work up a good
(working!) example for presentation types with parameters to place in
the archive to go along with this description.
If you're still with me, here it goes...
The documentation for presentation-typep on pg 366 sez:
"If the type name in "type" is or names a CLOS class, the method
[presentation-typep] is called only if "object" is a member of the
class and "type" contains parameters..."
Well, I defined a presentation type with parameters whose name is the
same as a CLOS class. Then I defined a presentation-typep and
presentation-subtypep method. The presentation-typep method is *only*
called when I mouse over a presentation whose type is something
*other* than the presentation type that these methods are specialized
for. For example, presentation-typep is called when I mouse over a
presentation of type clim:expression but not when I mouse over a
presentation of my type. This is *not* the behavior I see with
presentation types whose name is not the name of a CLOS class. In
that case, the presentation-typep method is always called.
>From this behavior, it appears that there is an "invisible"
presentation-typep method (behavior) for presentation types whose name
is the same as a CLOS class. This method determines whether the
application object associated with the presentation the mouse is
pointing at is a member (instance) of the CLOS class. Only meta
presentations (such as clim:expression) end up calling the
presentation-type method I have defined. For presentation types whose
name is *not* a CLOS class, there is no "invisible" behavior. The
presentation types presentation-typep method is always called to
determine the identity/associativity of the presentation type with an
application object.
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?
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. This is the behavior for
non-CLOS presentation types and should be the same (IMHO) for CLOS
presentation types too. If that's what I want to do, well so be it
(and if I get into trouble, thats my problem). In any case, shouldn't
the method always be called (as we shall see later)?
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
presentation-subtypep method is specialized for. The methods
arguments are two presentation type "specifiers." I call a
presentation type specifier something like:
name
(name parameters)
((name parameters) options)
The first argument is the presentation type specifier of the
presentation that the mouse is currently pointing at. It is
guaranteed to be of the same (presentation) type (or subtype of the
presentation type?) as the first arguments specialized (presentation
type) class name. The second argument is the presentation type
specifier for the current input context. This is defined by the
currently active accept or as defined in the dynamic extent of the
with-input-context macro.
So, I am confused as to the appropriate roles for presentation-typep
and presentation-subtypep. I guess that they both are used to
determine applicability of presentation handlers (translators or
actions) relative to the current input context? I am especially
confused because of the apparent behavior of presentation-typep not
being called in all cases for CLOS classes. Does presentation-typep
define the link/identity/associativity between an object and a
presentation type (the one that presentation-typep is specialized
for)? This doesn't seem correct as this relationship is held in the
presentation object(?). I suppose one can get into trouble though
when some arbitrary object is presented as some presentation type (via
with-output-as-presentation). Or, does presentation-typep define
presentation handler applicability between an object and the current
input context's presentation type specifier? Since presentation-typep
is not called even for parameterized CLOS classes, I can't see how
this method can determine handler applicability using the application
object for an input context.
Should the role of the presentation-subtypep method be to examine the
presentation parameters of the presentation that mouse is currently
pointing at and the current input context (and any presentation
parameters associated with it) in order to determine if the
presentation pointed at by the mouse (its presentation type specifier)
is really a subtype of the presentation type (according to its
presentation type specifier) that presentation-subtypep is specialized
for? If so, that might necessitate obtaining access to the
application object in order to make the determination (since the
presentation-typep method is not called in all cases in order to make
this determination). How do I do this? If not, is the role of
presentation-subtypep method to determine if the input context
(presentation type specifier) is a type or subtype of the presentation
type (specifier) of the presentation we are currently pointing at? If
so, then it seems that presentation-typep should be determining
handler applicability based upon the application object.
Blah.....
It occurs to me that maybe presentation-typep is supposed to determine
applicability of the current input context presentation type specifier
against the application object, and presentation-subtypep is supposed
to additionally determine applicability of the current input context
presentation type specifier against the presentation type specifier of
the presentation we are pointing at. I guess there is the potential
to present something of a presentation type specifier that does not
make sense semantically with respect to the actual state of the
application object.
The documentation for presentation-typep is misleading or the behavior
for presentation types whose name is the same as a CLOS class is
incorrect or I'm totally confused. Well, I am confused, there is no
doubt about that! Also (and *very* confusing) the university example
in the CLIM manual seems to be incorrect! Note that in that example
(pg. 176), even though I have a parameterized presentation type and I
have an accept that is parameterized I can actually accept an
application object that does not match the semantics of the accept
(whew!). Consider the following accept:
(accept `(student ,(find-department "Agriculture")))
Note that you can actually (incorrectly) accept a student that is not
a member of the agriculture department. I believe this is true
because the presentation-typep method is trying enforce a subset
relationship with the application object (and is never called as
outlined above). Is my analysis correct?
So, lets correctly fill in the following:
presentation-typep
Defines the identity/association between an application object and its
presentation.
or
Defines the applicability of a presentation handler in a given input
context with respect to an application object.
***NOTE - The following is really not clear in the documentation either!
Is this description correct?
Note that the lexically bound names of presentation type parameters
are the *defaults* as defined in the define-presentation-type form.
They are *not* the actual values of the parameters of the presentation
type specifier passed to presentation-typep! In order to gain access
to the values of the parameters of the presentation type specifier
passed to presentation-type, use the macros
with-presentation-type-decoded or with-presentation-type-parameters.
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.
presentation-subtypep
Checks congruency of type specifiers between the current input
context's presentation type specifier (as defined by accept or
with-input-context) and the presentation type specifier of the
presentation that the mouse is currently pointing at. The first
argument to presentation-subtypep is guaranteed to be a presentation
type specifier whose presentation type is the same (or a subtype of?)
as the specialized presentation type defined in the lambda list.
(Probably could say this better - help?)
----
Well, this brings up another problem! Being able to make the
determination if the current input context is a type or subtype of the
presentation (that is it's type specifier) that the mouse is pointing
at seems to assume/require that the presentation was originally
"present"ed in the right way. That is, it was presented with a
presentation type specifier that *includes* parameters. For example,
consider the following:
(defclass color () (<slot declarations>))
...
(define-presentation-method presentation-typep
(object (input-context-type color))
<make membership determination of moused presentation's object
against input context's presentation type specifier?>
...)
(define-presentation-method presentation-subtypep
((target-type color) input-context-type)
<make subtype determination of moused presentation's presentation
type specifier against the input context's presentation type specifier?>
...)
The following might work since presentation-subtypep has access to the
parameter for the red color object indicating that it is a primary
color.
(present *red-color-object* '(color :primary t))
(accept '(color :primary t))
will allow presentation-subtypep to work for the accept. But the
following will not work, as accept could still accept a color object
even if its not a primary since the present sez that this
presentations type specifier is essentially '(color :primary *).
(present *red-color-object* 'color)
(accept 'color)
HELP!!!!
ba
Brian H. Anderson
Boeing Commercial Airplane
(206) 234-0881
bha@atc.boeing.com
0,,
Follow-Ups:
Main Index |
Thread Index