Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!noose.ecn.purdue.edu!dirac!gibbs.physics.purdue.edu!sho
From: sho@gibbs.physics.purdue.edu (Sho Kuwamoto)
Newsgroups: comp.sys.mac.programmer
Subject: Re: ThinkC TCL's DoCommand() wish
Message-ID: <5236@dirac.physics.purdue.edu>
Date: 6 Jun 91 22:16:12 GMT
References: <1991Jun5.162514.29682@linus.mitre.org> <5228@dirac.physics.purdue.edu> <1991Jun6.171523.22922@linus.mitre.org>
Sender: news@dirac.physics.purdue.edu
Distribution: usa
Organization: Purdue Univ. Physics Dept, W.Lafayette, IN
Lines: 34

In article <1991Jun6.171523.22922@linus.mitre.org> gmarzot@mitre.org (G. S. Marzot (Joe)) writes:
>[Gives reasons why adding a user deined generic data field to DoCommand()
> would be good]
>
>The biggest problem that I 
>see is that all existing source, including the TCL itself would have to be 
>changed wherever DoCommand was used. However as Sho points out , in most 
>cases all that will be needed is to pad the existing call with a Null data 
>argument.  

Of course, if THINK C incorporated more C++ features, we could just
change the .h files to read:

    class CBureaucrat : public Cwhateveritwas {
        [...]
        void DoCommand(long theCommand, long data=0); 
    };

and we wouldn't have to worry about the .c files at all...

However, I still believe that this change causes conceptual problems. 
It means there will be two classes of commands: those that take no
arguments, and those that do.  Those that take no arguments can be 
used by the class library at will.  For example, a command with no
argument can be called in response to a menu event.  Those that do take
arguments are only going to show up in our code.  I think we should
keep these two types of commands conceptually seperate.  We could 
have a new DoMenuCommand() message which behaved the old way.

I'll have to think about your suggestion a little bit more.  

-Sho
-- 
sho@physics.purdue.edu <<-- you can almost hear the wheels turning.