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

Re: Using DEFINE-COMMAND


   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.  

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.  


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.

Thanks,

jeff morrill

0,,
Follow-Ups:
Main Index | Thread Index