Consider the display functions of the well known address book CLIM
demo. The code looks like this, for example for the
DISPLAY-CURRENT-ADDRESS function:
(define-application-frame address-book ()
;; ...
(:panes
(interactor :interactor)
(address :application
:incremental-redisplay t
:display-function 'display-current-address)
;; ...
))
(defmethod display-current-address ((frame address-book) stream)
(let ((current-address (slot-value frame 'current-address)))
(when current-address
(updating-output (stream :unique-id current-address)
(display-address current-address stream)))))
The CLIM 2 specification does not explicitly mention whether a display
function has to be ordinary or generic. Why does the address book
demo use generic display functions?
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
In article <··············@plato.moon.paoloamoroso.it>,
Paolo Amoroso <·······@mclink.it> wrote:
> Consider the display functions of the well known address book CLIM
> demo. The code looks like this, for example for the
> DISPLAY-CURRENT-ADDRESS function:
>
> (define-application-frame address-book ()
> ;; ...
> (:panes
> (interactor :interactor)
> (address :application
> :incremental-redisplay t
> :display-function 'display-current-address)
> ;; ...
> ))
>
> (defmethod display-current-address ((frame address-book) stream)
> (let ((current-address (slot-value frame 'current-address)))
> (when current-address
> (updating-output (stream :unique-id current-address)
> (display-address current-address stream)))))
>
> The CLIM 2 specification does not explicitly mention whether a display
> function has to be ordinary or generic. Why does the address book
> demo use generic display functions?
>
>
> Paolo
I don't think there is much of a reason to it. But it
ensures that the FRAME local variable actually is bound
to an object of class ADDRESS-BOOK. You could also
make sure that the STREAM local variable is bound
to something that makes sense in the presence
of UPDATING-OUTPUT.