CLIM mail archive
[Prev][Next][Index][Thread]

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
	   command.

    For the short term, I have defined my own DEFINE-COMMAND macro that
    offers for me a satisfying solution to these issues.  Consider these 
    random proposals:

    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.

0,,
References:
Main Index | Thread Index