[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Question about Presentations
Date: Mon, 15 Oct 90 15:52 EDT
From: firstname.lastname@example.org (Barry Margolin)
There's one potential problem with this, though. The internal
presentations are completely ignored, so if you try to ACCEPT a type
that the label would satisfy but the object wouldn't, the label will
still be ignored. For example, if you use a symbol as the label when
you present your frame, and then do (accept 'symbol), you won't be able
to click on the label.
When the label is representing another object, it is almost
always the right thing for it to not have any identity of
its own on the screen. This is why FORMAT ... "~A" <string>
doesn't create a STRING presentation. If a symbol is only
on the screen as a printed representation for something else,
then it has no business being considered as a symbol for
On the other hand, if a subset of SYMBOL serves as names for
some class of object, it may be correct to define your own
presentation type, as a proper subtype of SYMBOL, and present
it as that, inside your presentation as the object.
Of course, the same can be accomplished more generally, by
creating a translator from the object type to the name type.
Except, it doesn't always work, since translators don't
get chained together. (I think with the performance improvements
we put in when I was there, that translators could work in series
without any noticable performance degredation, but I never had
time to test that hypothesis).
Of course, Bob's solution has the same problem,
since the label's type is forgotten when it is converted to a string.
However, Bob's solution has a further problem that it won't work if
label is of a datatype that does not define a coercion to string (but
this can be fixed by changing (string label) to (format nil "~A"
I did that deliberately, to emphasize the role of the datatype