Question about Presentations

[RWK@fuji.ila.com (Robert W. Kerns)]

    Date: Mon, 15 Oct 90 15:52 EDT
    From: barmar@think.com (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
(ACCEPT 'SYMBOL).

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"
    label)).

I did that deliberately, to emphasize the role of the datatype
to ~A.