home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / tcl / 1180 < prev    next >
Encoding:
Internet Message Format  |  1992-08-12  |  2.7 KB
  1. Path: sparky!uunet!snorkelwacker.mit.edu!ai-lab!life.ai.mit.edu!tmb
  2. From: tmb@arolla.idiap.ch (Thomas M. Breuel)
  3. Newsgroups: comp.lang.tcl
  4. Subject: Re: why Tk doesn't scale well
  5. Message-ID: <TMB.92Aug13102903@arolla.idiap.ch>
  6. Date: 13 Aug 92 14:29:03 GMT
  7. References: <1992Aug13.012211.10452@news.eng.convex.com>
  8. Sender: news@ai.mit.edu
  9. Reply-To: tmb@idiap.ch
  10. Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
  11.     Perceptive)
  12. Lines: 47
  13. In-reply-to: connolly@convex.com's message of 13 Aug 92 01:22:11 GMT
  14.  
  15. In article <1992Aug13.012211.10452@news.eng.convex.com> connolly@convex.com (Dan Connolly) writes:
  16.  
  17.    Tcl VS SMALLTALK
  18.  
  19.    I think the programming model proposed by SmallTalk is the clear choice
  20.    for visual interface design.
  21.  
  22. I'm not so sure about that...
  23.  
  24.    [...] All but the last two have a full class system with inheritance and
  25.    subclassing supported by the language. It's possible (though painful) to
  26.    subclass Xt widgets to add state or messages. The Tk toolkit allows
  27.    class bindings to enhance the messages understood by a class, but it has
  28.    no mechanism for adding state to an interface object.
  29.  
  30.    For example, suppose I wanted to mimic an emacs buffer with a Tcl text
  31.    widget. In an OOP language, I could subclass the text widget, add
  32.    instance variables for things like the filename, editing mode, "dirty
  33.    bit", etc. In Tcl I have to cook up some method to associate this
  34.    state with the text widget.
  35.  
  36. Well, there are alternative, tried approaches to reuse of UI
  37. components that do not require inheritance. For example, you can
  38. filter the messages that go to the text widget (closely related:
  39. wrapping). 
  40.  
  41. Why would you choose such an alternative approach? First, it goes well
  42. with a thread/process model. Second, it reduces the risk that you
  43. accidentally come to depend on some property of the text widget that
  44. is visible only by descendants. In fact, I would argue that OOP for UI
  45. programming is an inferior implementation of such an approach...
  46.  
  47.    I wish Tk were built on top of XLisp -- then we'd have efficient
  48.    recursive list processing and an object system.
  49.  
  50. There are many X window interfaces based on Lisp (some even on XLisp).
  51. Why don't you use them? If that's what you like, what is it about Tk
  52. that makes you wish that it were built on top of XLisp?
  53.  
  54. Tk and TCL seem to me to be very reasonable compromises for living in
  55. the C/X11/networked world. I would hope that Tk ultimately also will
  56. explicitly support and encourage UI programming based on a
  57. multi-threaded environment; "send" is a first step. That could give
  58. you the flexibility of a message-passing approach to user interfaces
  59. with the simplicity of the Tk/TCL substrate.
  60.  
  61.                     Thomas.
  62.