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

Re: deactivating sub-menu items


  >  From @BBN.COM,@david.zfe.siemens.de:beschta@arms4.zfe.siemens.de Fri Oct 29 01:54:42 1993
  >  Date: Fri, 29 Oct 93 09:20:27 +0100
  >  From: Anton Beschta <beschta@arms4.zfe.siemens.de>
  >  To: SWM@stony-brook.scrc.symbolics.com, clim@BBN.COM
  >  Subject: deactivating sub-menu items
  >  Reply-To: beschta@zfe.siemens.de
  >  
  >     Date: Thu, 28 Oct 1993 13:53 -0400
  >     From: Scott McKay <SWM@stony-brook.scrc.symbolics.com>
  >  
  >     When I realized this hole was there, I came up with a kludge.  On the
  >     assumption that command names and command *table* names are disjoint,
  >     we could always allow (SETF (COMMAND-ENABLED <comtab-name>) NIL), and
  >     simply fix the one or two places in CLIM that call COMMAND-ENABLED to
  >     also check for the case of a command table being enabled/disabled.
  >  
  >     Is this kludge just too awful?  Should we come up with something real
  >     for this, or do people think it's OK to overload COMMAND-ENABLED to
  >     support enabling/disabling of command tables as well as commands?
  >  
  >  I don't think that's a good idea. The function name COMMAND-ENABLED
  >  simply suggests something different. And I always prefer function
  >  names that "talk" to me. From my point of view providing a
  >  COMMAND-TABLE-ENABLED function and an associated setf-method
  >  is much more natural.
  >  
  >  -Tony
  >  

I also like names that accurately represent the thing named.
The problem with the name COMMAND-TABLE-ENABLED is that when it talks
to you, it may be telling you a lie.   If you start with the name, you
may deduce a larger affect for the function than intended, such as
enabling/disabling all commands in the command-table independent of
whether it is associated with a pull-down menu.
Main Index | Thread Index