Len%AIP1%TSD@atc.bendix.COM (01/19/88)
Received: from GRACIE by HEART-OF-GOLD via CHAOS with CHAOS-MAIL id 2911; Mon 18-Jan-88 14:16:52 EST Date: Mon, 18 Jan 88 14:16 EST From: Sai-Cheong Arnold Chu <Gilgamesh@HEART-OF-GOLD> Subject: Post conference reflection - object-oriented toolkit To: "3077::in%\"xpert@athena.mit.edu\""@TSD1 Message-ID: <880118141623.4.GILGAMESH@GRACIE> Having just returned from the X conference last week, I wish to thank the organizers for a good job well done. It was a very enjoyable and informative meeting. I also wish to thank the attendees for being so enthusiastic. Regarding the future direction of X, I have but one concern. The structure of the Xtk toolkit is clearly evolving toward the object-oriented design approach. This, I believe, is a natural and very produtive apporach. Yet all widgets are written in vanilla C with some conventions adopted. NO object-oriented language support is available. I fear that this will cost dearly in the long run. Some toolkit developers indicated that they chose this route because no PD object-oriented language was available. I'm not convinced of the force of this arguement. Afterall, most of us uses licensed UNIX and licensed C compilers plus who knows how many more software tools. An additional license for C++ or Objectic C can't be prohibitive. Besides, there's also the approach the Andrew toolkit took: write your own preprocessor. Without an object-oriented language, all manipulation of the objects must be done using unenforcable conventions. The syntax is cluttered and may become unmaintainable. With an object-oriented language, object manipulation become natural and fairly painless. Many possible extensions become easier: debugging at object level, storing and loading object from databases, garbage collection of unused objects, and multiple inheritances. I strongly urge the Xtk toolkit developers to consider this issue. The views of others who've done object-oriented programming is also very welcome. Speaking personally, this issue is strongly discouraging me from using the Xtk toolkit. S. Chu chu%tsd%atc.bendix.com@relay.cs.net
Kimbrough@dsg.csc.ti.COM (Kerry Kimbrough) (01/20/88)
> Regarding the future direction of X, I have but one concern. The > structure of the Xtk toolkit is clearly evolving toward the > object-oriented design approach. This, I believe, is a natural and > very produtive apporach. Yet all widgets are written in vanilla C > with some conventions adopted. NO object-oriented language support is > available. I fear that this will cost dearly in the long run. > ... > Without an object-oriented language, all manipulation of the objects > must be done using unenforcable conventions. The syntax is cluttered > and may become unmaintainable. With an object-oriented language, > object manipulation become natural and fairly painless. Many possible > extensions become easier: debugging at object level, storing and > loading object from databases, garbage collection of unused objects, > and multiple inheritances. > ... > I strongly urge the Xtk toolkit developers to consider this issue. > The views of others who've done object-oriented programming is also > very welcome. Speaking personally, this issue is strongly > discouraging me from using the Xtk toolkit. > S. Chu <chu%tsd%atc.bendix.com@relay.cs.net> I heartily concur. I'd like to point out the special implication for CLX users who program X applications in Common Lisp: callout to a foreign-function Xtk library is a sandtrap. It may look like a quick way out now, but it won't be long before you'll wish you were using the standard CLOS OOPS like everybody else. Then, you'll find that the half of the Xtk machinery which is devoted to simulating an OOPS will be unnecessary.