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.