Does anyone know about why in CLIM there are two ways to provide
callbacks on gadgets--via specializing a method and also by providing
a function object via an initarg? (Be warned, I know just enough about
CLIM to ask that question--I went looking into the docs to see if it
would provide a good example of an API that uses closures as
callbacks.)
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
>
> Does anyone know about why in CLIM there are two ways to provide
> callbacks on gadgets--via specializing a method and also by providing
> a function object via an initarg? (Be warned, I know just enough about
> CLIM to ask that question--I went looking into the docs to see if it
> would provide a good example of an API that uses closures as
> callbacks.)
clim is by no means unique in this regard.
in gui programming there are occasions when the behaviour should be
specialized by class and the are occasions when it should be specialized by
prototype or instance. it's just the nature of the problem that sometimes one
needs to introduce the same behaviour in many places (in which case one
specializes the control/item/widget and a specializes the method) and
sometimes one needs to differentiate the behaviour of an otherwise
indistinguishable prototype (in which case one specifies a function to the
instance. it's the same as specifying color or size. a declarative description
of a user interface is good, but if carried too far it becomes cumbersome.
one must also consider that the action may well wish to combine with existing
general aspects. which is difficult to do in clos for an instance-specific
function unless one factors the action protocol appropriately.
if one examines, for example, the toolbox interface in mcl, one observes that
controls, in general, rely on a function called <control-class-name>-action to
specify their reaction to user gestures. the respective class definition, in
general, includes a slot <control-class-name>-action-function or just
action-function and the respective general definition for
<control-class-name>-action looks for a binding for
<control-class-name>-action-function. i suspect lacking one it does nothing,
but it would also be possible to have it delegate to a more general definition
if one existed.
one of the things which pre-clos (object-lisp) versions of mcl supported was
the ability to integrate an anonymous action function in the respective
class's effective method. as if one specified with-methods with an eql specializer.
...