bilbo.geoff@SEAS.UCLA.EDU (Geoff Kuenning) (01/07/88)
These are a couple of comments on the December toolkit Intrinsics
document which I was asked to post for discussion. The page references
are to the Postscript output available on the xstuff server.
(1) In Section 5.10, page 16, the class inheritance mechanisms are
discussed, with an example showing how XtInheritInitialize works.
However, it is unclear why the example goes through so many
gyrations. Why does the first call do special processing
that will only be executed the first time (since the pointer
to the inherit routine is replaced with the superclass's
routine)? Also, why is the XtClass field replaced with the
superclass, but only on this first call?
(2) Section 15.1 discusses the command line parsing facilities. While
I really have no objection to the toolkit's reinvention of the wheel, I
must strongly object to the current design which forces this
ill-conceived, nonstandard, and incompatible argument-processing
philosophy on everyone who wants to use the toolkit. At LEAST
make it an option so people who want to sell standard software
can bypass it, even if it is inconvenient.
Geoff Kuenning geoff@lcc.ucla.edu geoff@ITcorp.comasente@decwrl.DEC.COM (01/08/88)
(1) The gyrations done by the inheritance routines are necessary to prevent an infinite loop when inheriting a routine that is itself the same inherit routine. Without it, you would just keep calling the Inherit routine over and over. I agree that it is poorly described, and this should improve soon. Also, the entire mechanism by which inheritance is done is currently under review and is likely to change. (2) I fail to understand your objections to the command line parsing. Could you explain in what way this is an "ill-conceived, nonstandard, and incompatible argument-processing philosophy"? -paul asente
deboor@nutmeg.Berkeley.EDU.berkeley.edu (Adam R de Boor) (01/08/88)
The first-time gyrations occur because of multiple-level inheritance. If you have a three-level heirarchy: A | B | C where a method is defined in A and both B and C want to inherit it, if the class of C weren't changed to B, the call would loop infinitely, since the superclass would always appear to be B (the Inherit function would copy the Inherit function from B to C, then call itself...). I, too, was confused by this first time out. Took me a while to justify it... a
bilbo.geoff@SEAS.UCLA.EDU (Geoff Kuenning) (01/08/88)
The command-line parsing is, as I said, "ill-conceived, nonstandard,
and incompatible." In support of my statements:
(1) The easiest charge to support is "nonstandard". Check out getopt(3)
if you have System V or 4.3, or the Posix document. There is an
explicit and adopted standard for Unix command line processing.
It specifies that (a) switches may be only a single character,
(b) switches may be introduced ONLY by the "-" character, and (c)
arguments may be either concatenated or separate from their
switches. The existing toolkit code violates all three of these
specifications.
Many people have argued that single-character switches have
significant drawbacks, so that it is necessary to ignore the standard.
In general, these people are disregarding the fact the decision was
made after careful consideration of these drawbacks and of the
impact on the existing Unix community of changing the standard.
When one chooses to ignore the decision of the Posix committee, one
is in effect saying that one knows more about Unix and the Unix
community than they do. Before doing this, I'd think about checking
the membership of the committee and seeing if I really think I
know more than them. Doug Gwyn, just to name one member, is hardly
a schmuck.
(2) The existing command-line processing is incompatible with existing
Unix, existing standards, and existing software. I already discussed
the standards issue (getopt) above. As to existing Unix, note that
the *only* standard Unix command that takes multi-character dash-separated
switches is "find", which is universally cited as an example of
"strange" command-line switches. ("dd" also takes multi-character
switches, and is even stranger).
Existing software expects single-character switches, usually processed with
getopt. A conversion to X-Windows (e.g., gnumacs) requires the porter to
either throw out the existing getopt-based code and use the toolkit code,
convert the toolkit to use getopt, or work with a godawful conglomeration.
(3) The existing toolkit argument processing is ill-conceived for a whole bunch
of reasons. First, it is a nonstandard reinvention of the wheel that
forces any toolkit user to violate existing standards. Second, it
forces all toolkit users to accept so-called "standard" interpretations
of certain switch strings (even though the standard exists only within the
toolkit). Third, the switch variations currently supported (SepArg, IsArg,
etc.) contain too many options (one lesson of comparing VMS with Unix
is "don't give the user options!") that are of limited usefulness
and encourage still more nonstandard code (notablyIsArg). Fifth,
it requires toolkit porters to re-implement the OS-specific command-line
processing, even though the OS already provides a perfectly usable
command-line routine such as getopt. Sixth, it splits command-line
parsing into more than one place, making maintenance and debugging that
much more difficult.
In summary, *please* don't force this idea on us. Provide it as an option
if you really want to encourage to X community to violate existing standards
and write software that the government won't buy. But kindly provide a
way around this silly code for those of us who understand why it's better
to stick with a flawed standard than to go off in a new direction all
our own.
Geoff Kuenning geoff@lcc.ucla.edu geoff@ITcorp.comhaynes@DECWRL.DEC.COM (01/09/88)
Geoff, The only thing XtInitialize *requires* to be in the argv that you pass it is a host spec. If you don't want to use XtInitialize's command line parsing, parse argv yourself, then pass in to XtInitialize either a null argv and 0 argc (in which case it will get the display from the environment), or pass in an argv with just the host spec, and an argc of 1. -- Charles
paulsh@denali.gwd.tek.COM (Paul Shearer) (01/12/88)
Geoff, I strongly agree with your position on command line arguments. Thanks for your input to the xpert mailing list. Paul Shearer M.S. 61-277 Tektronix, Inc. P.O. Box 1000 Wilsonville, OR 97070-1000 W (503) 685-2137 tektronix!shark!paulsh