larry@celia.UUCP (Larry Weinberg) (06/05/91)
I have been using Think C's class libraries for some time now and
I keep running into the situation where I wish I could send some
parameters, or a pointer, along with the command code to the DoCommand()
method of CBureacrat class objects.
Why insn't it implemented as:
CBureaucrat::DoCommand(long theCommand, long data)
(data could be a pointer to any type of structure that might be
needed)
Am I alone with this wish? Since I don't have this feature, and I
don't want to modify the TCL sources because I want to remain compatible,
I create special methods for subclasses that I call directly, hence
I must cast explicitly to a given subclass therefore loosing some of that
beautiful object oriented generality of not having to know what type of
object I am passing a message on to.
Am I missing something obvious? Is there some truer message passing
scheme implemented in the Class Library's chain of command?
Or should I take the plunge and modify the CBureaucrat class and have problems
with future versions?
Larry
--
Larry Weinberg Rhythm & Hues, Inc.
INTERNET: celia!larry@usc.edu celia!larry@tis.llnl.gov
UUCP: ...{ames,hplabs}!lll-tis!celia!larry
We can't all, and some of us don't. That's all there is to it. -- Eeyoregmarzot@mitre.org (G. S. Marzot (Joe)) (06/05/91)
In article <1042@celia.UUCP> larry@celia.UUCP (Larry Weinberg) writes: > I keep running into the situation where I wish I could send some > parameters, or a pointer, along with the command code to the DoCommand() > method of CBureacrat class objects. > > Why insn't it implemented as: > > CBureaucrat::DoCommand(long theCommand, long data) > > (data could be a pointer to any type of structure that might be > needed) > > Am I alone with this wish? You definitely are not. I agree whole heartedly in favor of a more flexible interface to DoCommand and your example looks perfect. I also have a feeling now is the time to make ourselves heard just in case any new editions of the TCL are forthcoming. In the event that the right person at Symantec does not get this post I think I will pass it along myself. -gsm Email: gmarzot@linus.mitre.org (standard disclaimer)
sho@gibbs.physics.purdue.edu (Sho Kuwamoto) (06/06/91)
In article <%> gmarzot@mitre.org (G. S. Marzot (Joe)) writes: >In article <@> larry@celia.UUCP (Larry Weinberg) writes: >> >>[I want] CBureaucrat::DoCommand(long theCommand, long data) > >[...] I agree whole heartedly in favor of a more >flexible interface to DoCommand and your example looks perfect. [...] The TCL calls gGopher->DoCommand() whenever the user selects a menu item. As far as I can tell, this is the main reason that DoCommand() exists. Given that, we should consider how adding another arg would affect this. What would happen when the user selects a menu? The best we could hope for with this new scheme is that it would call DoCommand() with data = 0. If you want something like the above, write your own method. Call it MyDoCommand() or something. Have it call DoCommand() when appropriate. -Sho -- sho@physics.purdue.edu
gmarzot@mitre.org (G. S. Marzot (Joe)) (06/07/91)
> In article <%> gmarzot@mitre.org (G. S. Marzot (Joe)) writes: > >In article <@> larry@celia.UUCP (Larry Weinberg) writes: > >> > >>[I want] CBureaucrat::DoCommand(long theCommand, long data) > > > >[...] I agree whole heartedly in favor of a more > >flexible interface to DoCommand and your example looks perfect. [...] In article <5228@dirac.physics.purdue.edu> sho@gibbs.physics.purdue.edu (Sho Kuwamoto) writes: > If you want something like the above, write your own method. Call it > MyDoCommand() or something. Have it call DoCommand() when appropriate. The debate over whether to alter a class library in a somewhat obtrusive way (i.e, changing argument lists) high up in your tree vs. providing desirable new behaviors only in leaf nodes as needed is a long standing one. There is also the option of adding methods high up in the tree without altering existing ones, this is less obtrusive but has some drawbacks as well. In the case of this DoCommand issue I will try to point out what I see as the +'s and -'s and hopefully everbody(Symantec in particular) can sort out the best course. I feel the Bureaucratic DoCommand method was not just intended for dispatching menu commands but as general way in which (all)Bureaucrats could communicate coupled with the "if you can't handle it,Pass it to your Supervisor" behavior. For example the ArtClass uses it in conjunction with the ToolPalette to set the current tool and I have used it for other messages that I wanted to travel up the chain of command. The addition of a data argument would greatly increase its applicability without adding alot of clutter either in all the leaf nodes that need that behavior or as a similar but slightly different method added thoughout the tree at stategic spots. It is a generally accepted OOP concept to have Classes and methods which are unique and have a well defined exclusive role.(i.e., duplication and overlapping responsibilities are less desirable). Now for the drawbacks, and because my opinion is no longer a secret I will offer a counter- counter point as well. 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. From my experience(in certain libraries we have had method arg lists change) this task is not fun but nor is it very difficult. Also I am sure if the change originated with Symantec they would do the work of changing the TCLinnards to be self-consistent so all thats left is your own source. It seems inevitable that the TCL will(should) evolve and with proper guidance at the helm it will continue to be an excellent time saving and highly capable application frame work. -gsm ps. let's not be totally shackeled by backward compatibility. That's why IBM'sPC's still have to work around a 640k barrier. In this case the price is very small for some decent progress. Email: gmarzot@linus.mitre.org (standard disclaimer)
sho@gibbs.physics.purdue.edu (Sho Kuwamoto) (06/07/91)
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.
Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) (06/08/91)
Larry Weinberg writes in a message to All
LW> Why insn't it implemented as:
LW> CBureaucrat::DoCommand(long theCommand, long data)
LW> (data could be a pointer to any type of structure that might
LW> be needed)
LW> Am I alone with this wish? Since I don't have this feature,
LW> and I don't want to modify the TCL sources because I want to
LW> remain compatible, I create special methods for subclasses that
LW> I call directly, hence I must cast explicitly to a given subclass
LW> therefore loosing some of that beautiful object oriented generality
LW> of not having to know what type of object I am passing a message
LW> on to. Am I missing something obvious? Is there some truer message
LW> passing scheme implemented in the Class Library's chain of command?
LW> Or should I take the plunge and modify the CBureaucrat class
LW> and have problems with future versions
One thing that you could do is implement a "gCommandDataPtr" global variable.
Whenever you wish to pass auxilliary data up the chain of command, set this
variable to your dataPtr. Any command that expects extra data could check this
global and set it to nil/null when it is done (if it's already nil/null then
no data was passed). You could have a change to yourApplication's DoCommand
that would set the ptr to nil/null if it yourApplication's DoCommand was reached
with a non-sensical command. This is a little kludgey but obviates (whataword)
the need to rewrite the TCL's.
Lawson
--
Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!300!15.88!Lawson.English
Internet: Lawson.English@p88.f15.n300.z1.fidonet.org