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

Quickie question on CLIM application command semantics and approach

    Date: Wed, 13 Nov 1991 14:37 EST
    From: curt@eraserhead.jpl.nasa.gov (Curt Eggemeyer)

    I have two very simple questions about what would the best way to implement
    application commands on my CLOS objects.

    1) If I have two or more clos class objects that I want to execute the same
    application command on. Which is the better approach?

    Lets say my classes are called A and B.

    (define-my-application-command (do-something :name t) ((object (or A B))
      ...)

    or can I do it this way

    (define-my-application-command (do-something :name t) ((object 'A))
      ...)

    (define-my-application-command (do-something :name t) ((object 'B))
      ...)

This one doesn't work.  The second definition will replace the
first.  The OBJECT argument is not being specialized by A and B
in the CLOS sense.  These are presentation types, not classes,
and control what parser is used to ACCEPT the argument.

I don't know how well CLIM 1.0 handles (ACCEPT '(OR A B)); you 
may need to define a presentation type A-OR-B with a parser that
knows how to tell from the syntax of the input whether it's A or B.

Of course, if you never enter commands from the keyboard, you may
not care about how well the parser works, but at least this should
make it more clear to you what the semantics of the types in the
command argument list mean.

    Is it more efficient, especially if I want the same command "do-something"
    to the object slightly differently based upon its type.

This isn't really an area to worry about tiny efficiencies.  Remember,
you're going through the entire UI, parsing, mouse handling, etc.
This are much much larger performance-wise than any question of how
you define or invoke the command.

    2) Is there a way to eliminate needing a colon on the keyword args in the
    command.  

Hmm, so you ARE using the keyboard, so the issue of parsers IS
relevant to you.

	      I want to emulate &optional arg another-arg and so on capability within the application command definition.

Yes, there are ways, but I think I'll let someone more qualified in
this area tell you just how.  It's not quite trivial.

    If I do

    (define-my-application-command (do-something :name t)
		    ((object A) &key one-way another-way) ...)

    and invoke the command in my interactor pane it shows up as:

    do-something OBJECT-A-PRINT :one-way   as I type it in.  How can I eliminate
    those colons.  Or am I stuck with including my own calls to ACCEPT within
    the command definition form to emulate optional args?

0,,
Main Index | Thread Index