Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!think!barmar
From: barmar@think.COM (Barry Margolin)
Newsgroups: comp.windows.x
Subject: Re: For comment: problems with toolkit arg processing/philosophy
Message-ID: <12142@think.UUCP>
Date: Tue, 24-Nov-87 05:34:39 EST
Article-I.D.: think.12142
Posted: Tue Nov 24 05:34:39 1987
Date-Received: Fri, 27-Nov-87 05:22:33 EST
References: <871106083928.4.RWS@KILLINGTON.LCS.MIT.EDU> <127@bacchus.DEC.COM> <1852@geac.UUCP>
Sender: usenet@think.UUCP
Reply-To: barmar@sauron.UUCP (Barry Margolin)
Organization: Thinking Machines Corporation, Cambridge, MA
Lines: 26

In article <1852@geac.UUCP> daveb@geac.UUCP (Dave Collier-Brown) writes:
>  Hey people, why not push the problem out of the X world by saying
>that client programs are advised to use getopt, and be prepared to
>have different implementations of getopt for different
>convention-sets selected in their linkage directives.  After all,
>this is a POSIX/VMS/whatever issue, not an X issue.

The purpose of the argument-processing routine in the toolkit is to
make it easy for all client applications to have a consistent command
interface.  I agree with those who said that the implementation on a
particular OS should be consistent with other commands on that OS,
rather than making the argument processing consistent across all X
implementations.  However, this should be done by having a different
version of the toolkit routine (or appropriate #ifdef's in a single
implementation), NOT by pushing the burden of writing the argument
processing onto the application programmer.  For one thing, if a
future revision of X has use for a new command option, it can be added
to the toolkit and all clients will pick it up automatically the next
time they are relinked.

---
Barry Margolin
Thinking Machines Corp.

barmar@think.com
seismo!think!barmar