Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ucbvax!atc.bendix.COM!Len%AIP1%TSD
From: Len%AIP1%TSD@atc.bendix.COM
Newsgroups: comp.windows.x
Subject: Post conference reflection - object-oriented toolkit
Message-ID: <8801190501.AA24193@ATHENA.MIT.EDU>
Date: 18 Jan 88 18:14:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 37

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