Path: utzoo!utgpu!water!watmath!clyde!rutgers!cmcl2!nrl-cmf!ames!pasteur!ucbvax!dsg.csc.ti.COM!Kimbrough
From: Kimbrough@dsg.csc.ti.COM (Kerry Kimbrough)
Newsgroups: comp.windows.x
Subject: Re: Post conference reflection - object-oriented toolkit
Message-ID: <2778598189-938917@Sierra>
Date: 19 Jan 88 16:49:49 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 29


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