CLIM mail archive
Re: Using DEFINE-COMMAND
Date: Fri, 8 Mar 1991 13:26 EST
From: Jeff Morrill <jmorrill@BBN.COM>
Date: Fri, 8 Mar 91 11:36 EST
From: "David C. P. Linden" <DCPL@fuji.ila.com>
In 0.9, there are three things that D-F-C does over D-C:
-- D-F-C can provide automatic ways of adding the command to the
frame's command table.
-- D-F-C gives the code access to the frame associated with this
invocation of the command, whereas D-C should not assume anything
about particular frames.
-- D-F-C allows the same command to exist on several frames, e.g.,
COM-EXIT, and to write :before/:after/:around methods for the
For the short term, I have defined my own DEFINE-COMMAND macro that
offers for me a satisfying solution to these issues. Consider these
1. Define-command should accept a command table as a keyword option,
adding it to the table if provided but not caring too much either way.
This is much more convenient than having to do it in a separate top
level form every time.
CLIM Release 1.0 does this.
2. Specializing commands on the application frame makes quite a bit
of sense, particularly for the case of a toolbox that gets
inherited by several applications at once. In that case, the ability
to define :before/:after/:around methods could become
a big advantage. I admit that I haven't yet taken advantage of
this feature, but I think I'd be inclined if it seemed to be a
stable feature of CLIM.
3. It doesn't make much sense, however, to have D-F-C define a
method and D-C define a function. Define-command should accept a
frame class as a keywork option, and it should define a method
specialized on that class. The default frame class should be T.
CLIM Release 1.0 made the simpler decision: commands are implemented as
vanilla functions. It may be that the simpler decision is the wrong
one, and that in CLIM Release 2.0 commands should be generic functions
whose first argument specializes on the frame.
However, I think that it should be clearly demonstrated that being able
to specialize commands is really needed, and is not just a "neat
feature". If you were to look at all of the applications written using
Dynamic Windows, I think that you would find only a few places where
being able to specialize commands by adding :before/:after/:around
methods turns out to be useful, and that the ability to import commands
covers almost all of the common cases. (I just surveyed all of the
applications in my world, and could find only one command that would
conceivably benefit, and that was the various "exit" commands. However,
they are typically so short that it doesn't really matter.)
In other words, I like how define-frame-command exists today, but
I want define-command to do those things as well. I hope you will
consider redefining the responsibilities of define-command for 2.0.
Main Index |