January 94 - A Case Against DoCommand
A Case Against DoCommand
Andy Dent
I really want to eliminate DoCommand. This article is a slightly theoretical discussion
of the benefits and reasons for removing DoCommand and replacing it with a better
mechanism. These theories have yet to be tested in a real program, more for lack of
time (as yet) than intention. Responses will be welcomed!
Why Change?
Being one of the fortunate (few?) with a dual monitor Mac, I've come to appreciate the
strengths of the Think class browser. With most of your class structure visible, the
browser's features are usable. One favorite is the option-double-click on a method
name to highlight all the implementors of that method.
Except for DoCommand, which is almost an invisible class hierarchy in itself!
DoCommand is messy, and you have to look at each and every DoCommand method
directly to see where commands are handled.
DoCommand is also inefficient-a command has to fall through a case statement in each
level below the method that finally handles the command. So why not dispense with the
obscure and inefficient, and have a method for each command-DoCmdNew, DoCmdOpen,
DoCmdClose?
How Much needs Changing?
Obviously, each implementor of DoCommand in the current hierarchy will have to
implement a few DoCmdXX methods. Unfortunately, you can't avoid modifications and
just subclass the TCL. At the very least, a stub method must be added to the abstract
class CBureaucrat for each of your DoCmdXX methods. (The OODL people are probably
looking smug at this point-we C++ and Object Pascal die-hards just have to put up
with adding methods to base classes, if we want polymorphic dispatching).
Bear in mind that CBureaucrat is going to have to define these stubs for each and every
DoCmdXX method you implement. This implies modifying CBureaucrat for each
project, although a fair amount of commonality will reduce the number of changes each
time.
Dispatch Blues
Adding DoCmdXX methods is fine for handling the commands, and there are many places
where a call to DoCommand is performed, with an explicit command number constant.
These can be easily changed e.g.: CApplication::DoOpenOrPrintDocEvent changes from
sending:
gGopher->DoCommand( cmdPrint)
to
gGopher->DoCmdPrint().
There are two general dispatchers in TCL which present more of a problem.
CSwitchboard::DoKeyEvent and CDesktop::DispatchClick both make use of the following
code to dispatch commands based on a menu choice (either by command-key or mouse
action).
gGopher->DoCommand(gBartender->FindCmdNumber)
A reasonably elegant way to cope with this, the only truly general use of DoCommand,
would be to have your own table object (or plain function), changing slightly for each
project. This may sound like an overhead, but it would contain only a single case
statement, as opposed to the cases in every single DoCommand used at present. A
sample dispatch table function is shown below, along with the code to call it.
myDoCommandDispatch(gBartender->FindCmdNumber)
myDoCommand( long theCommand)
Str255 theDA; /* Name of Desk Accessory to open */
SFReply macSFReply; /* Standard File reply record */
if (theCommand < 0) {
if (HiShort(-theCommand) == MENUapple) {
GetItem(GetMHandle(
MENUapple), LoShort(-theCommand), theDA);
OpenDeskAcc(theDA);
}
} else {
switch (theCommand) {
case cmdNew:
gGopher->DoCmdNew();
break;
case cmdOpen:
gGopher->DoCmdOpen();
break;
Wrap-up
So, there's the theory. We get faster command handling and a great improvement in
browsing at the cost of having to modify some TCL classes for each project.