Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!maverick.ksu.ksu.edu!kuhub.cc.ukans.edu!wuarchive!usc!snorkelwacker.mit.edu!linus!linus!mitre.org!gmarzot
Newsgroups: comp.sys.mac.programmer
Subject: Re: ThinkC TCL's DoCommand() wish
Message-ID: <1991Jun6.171523.22922@linus.mitre.org>
From: gmarzot@mitre.org (G. S. Marzot (Joe))
Date: 6 Jun 91 17:15:23 GMT
Sender: news@linus.mitre.org (News Service)
References: <1042@celia.UUCP> <1991Jun5.162514.29682@linus.mitre.org> <5228@dirac.physics.purdue.edu>
Distribution: usa
Organization: The MITRE Corporation
Nntp-Posting-Host: gmarzot.mitre.org
Lines: 57

> 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)