CLIM mail archive
Re: deactivating sub-menu items
> From @BBN.COM,@david.zfe.siemens.de:firstname.lastname@example.org Fri Oct 29 01:54:42 1993
> Date: Fri, 29 Oct 93 09:20:27 +0100
> From: Anton Beschta <email@example.com>
> To: SWM@stony-brook.scrc.symbolics.com, clim@BBN.COM
> Subject: deactivating sub-menu items
> Reply-To: firstname.lastname@example.org
> 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.
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 |