home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / tcl / 1067 < prev    next >
Encoding:
Internet Message Format  |  1992-07-29  |  2.7 KB
  1. Path: sparky!uunet!cis.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!sprite.Berkeley.EDU!ouster
  2. From: ouster@sprite.Berkeley.EDU (John Ousterhout)
  3. Newsgroups: comp.lang.tcl
  4. Subject: Re: How do I imbed tcl in an application
  5. Date: 29 Jul 1992 16:15:24 GMT
  6. Organization: U.C. Berkeley Sprite Project
  7. Lines: 40
  8. Distribution: world
  9. Message-ID: <156g6sINNnp2@agate.berkeley.edu>
  10. References: <1992Jul27.175107.7633@rchland.ibm.com> <ADRIANHO.92Jul27175403@barkley.berkeley.edu> <1992Jul28.113922.19882@cas.org>
  11. NNTP-Posting-Host: tyranny.berkeley.edu
  12.  
  13. A couple of comments on this.
  14.  
  15. First, in response to Kevin Kenny's question about the noun-versus-verb
  16. approach to Tcl commands:
  17.  
  18.     John Ousterhout has experimented with both methods: files in Tcl are
  19.     identified by handles, while widgets in Tk are independent commands
  20.     having client data.  John, do you have anything to add about the
  21.     tradeoffs?
  22.  
  23. I don't have much to add to this.  To tell the truth, I never thought
  24. very explicitly about this choice until seeing it in Kevin's message.
  25. I used the handle approach for files because that seemed a natural
  26. imitation of the corresponding UNIX C procedures, and I used the
  27. "object-name-as-command" approach for Tk widgets because that provided
  28. for a uniform approach across all widget types and allowed inidividual
  29. widget types to define different sets of sub-commands without polluting
  30. the Tcl command space.  In retrospect, I think I like the "object-name-as
  31. command" approach better, but I think it works best for moderate numbers
  32. of objects (10's or 100's).  If there are a million objects, then I think
  33. the handle approach would have significantly lower overhead.
  34.  
  35. Second, Larry Virden asked about the extension at the level of sub-commands:
  36.  
  37.     Something that I have been wondering about along these lines is based on
  38.     John's two initial papers.  They described the tcl/tk environment in 
  39.     such a way that it seemed that a user would be able to write their own
  40.     extended sub-options for tcl commands and then the application would
  41.     read these extentions / parameters , etc and allow the user customizations.
  42.     
  43.     Did I get the wrong idea?  Is there a way for me to add new commands to
  44.     a tcl/tk application automatically, or does each application need to add
  45.     code to handle this possibility?  If so, where does that fit into the
  46.     previously described skeleton that you folks are talking about?
  47.  
  48. You can add commands, but you can't add subcommands to existing commands.
  49. For example, if you wanted to add a "remove" option to the string command,
  50. so that you could say "string remove <string> <letter>" to remove all
  51. instances of <letter> from <string>, you'd have to modify the C code that
  52. implements "string".
  53.