gdykes@batcomputer.tn.cornell.edu (Gene Dykes) (04/22/89)
I'd like to voice my support of Dan Heller's suggestion that there
ought to be a cleaner division of Xt intrinsics and the Xaw toolkit,
There should also be some guidelines for toolkit writers concerning
certain name derivations.
The Intrinsics have some very good conventions for deriving various
names given the class name of a widget, but there should also be a rule
for deriving the class name of a widget given its functional name and
the toolkit's ID name. (By "rule", I mean either a strict convention or
a strongly encouraged guideline.) Without these guidelines, what is
mere confusion now will become linker collisions in the future for
the many of us who depend on utilizing multiple toolkits in a client.
The following table presents a summary of the current taxonomies for
deriving names in Toolkits. Except for Xcu, a toolkit that I wrote that
will appear in comp.sources.x soon, all information in this tabulation
comes from the MIT X11R3 distribution. The ID in row 1 is substituted
appropriately where "id" or "Id" is found in the subsequent entries.
Athena HP Sony Cornell U.
---------- ---------- ----------- ----------
Toolkit ID | aw w sw cu
Library | libXid.a libXid.a libXid.a libXid.a
Source Dir | Xid Xid Xid Xid
Widget classname | Class XidClass IClass IdClass
Public .h file | X11/Class.h Xid/Class.h X11/IClass.h X11/IdClass.h
Public functions | XtFunc() XidFunc() XtIFunc() IdFunc()
Resource values | XtValue XidVALUE Xtvalue IdValue
Each of the last four items follow inconsistent naming conventions.
In fact, no two toolkits follow the same rules. To remedy that,
I suggest the following guidelines. These are based on the following
rule of thumb: be as concise as possible while maintaining an adequate
lack of ambiguity.
Issue Convention Example
----- ---- -------
Set ID id aw
Library libXid.a libXaw.a
Source Dir Xid Xaw
Widget classname IdClass AwLabel
Public .h file Xid/(Id)Class.h Xaw/AwLabel.h (or Xaw/Label.h)
Public functions IdFunc() AwFunc()
Resource values IdValue AwJustifyCenter
Now for a discussion of why I think the rules above are the most appropriate.
Set ID : id
Library : libXid.a
Source Dir : Xid
Unanimous agreement here. If a compound toolkit id were employed,
it would be compoundId.
Proposed Convention for Widget classname : IdClass
"IdClass" :
"Class" : ambiguous.
"XidClass" : not concise; 'X' conveys no information
"IClass" : inconsistent with the other Intrinsics naming conventions
since it involves dropping a letter from the ID, and it leads
to potential conflicts with other names.
Some people might argue that it's all right to have more than one
widget of the same name. After all, you can always load the libraries
in the order necessary to retrieve the one you want first. But this
is wrong, for two reasons:
1) Each of the two widgets may have unique features that make it
desirable to use each of them in different parts of the application.
2) Suppose you want the one widget from toolkit A, and a second
widget from toolkit B, when both of them appear in both toolkits?
Presumably, HP and Sony recognized that this was a problem, and that is
why they stuck a prefix onto their widget classes. I felt so, too.
However, we each chose a different scheme. This is not a good situation.
Besides being confusing, both the Sony and Xaw methods lead to potential
conflicts. Adopting a proper convention would eliminate this problem.
Proposed Convention for Public .h file : Xid/IdClass.h, or
: Xid/Class.h
"X11/Class.h" : ambiguous, no ID in the name, should be in own directory
"Xid/Class.h" : no ID in the name, but perhaps OK.
"X11/IClass.h" : drops a letter from the ID, should be in own directory
"X11/IdClass.h" : should be in own directory
It is important that the ID show up in either the directory or the
filename, both to resolve conflicts and to provide an indication
in the source files of where the widget is coming from.
Proposed Convention for Public functions : IdFunc()
"IdFunc()" :
"XtFunc()" : Implies all functions need unique *functional* name parts
"XidFunc()" : Not concise - the 'X' provides no info.
"XtIFunc()" : Not concise - the "Xt" provides no info; letter dropped.
Without guidelines, conflicts here are also very likely, since widgets
with totally different utility could pick the same function names to
perform a common function.
Proposed Convention for Resource values : IdValue
(enumerations, definitions, etc.)
This applies to things like "XtJustify". Intrinsics resource value
definitions would start with Xt, but no others. Using the Xaw method,
not only does a toolkit writer have to check out the definitions in
StringDefs.h, but he has to check out every other toolkit in existence
to ensure a lack of conflicts. This is clearly unrealistic.
Assuming that somebody agrees with me on this proposal (perhaps a
rash assumption), let me attempt to counter a likely objection, namely,
"There's too much code out there now that depends on these toolkits"
The amount of code that will depend on all these toolkits and
future toolkits next year alone will probably dwarf what depends
on them this year, and two or three years down the road it will
be ludicrous to consider that what's out there today is a large amount
of code.
I know there is always the decision to be made about breaking existing
code versus letting things getting even more muddled, but with a likely
proliferation of toolkits just around the corner, I think there is
some urgency in setting up naming conventions for toolkits. It is
important that this issue be clear by the time R4 hits the street.
In addition to the plain old nuisance of employing multiple nomenclatures
within an application, there is the prospect of automatic code generators
that will be totally stymied by a lack of standards here.
It won't be painless, but for the most part it will be easy to provide
shell scripts that can sed their way through a directory and convert
one naming scheme to another. I'm quite sure I could convert my widget
set to this scheme in a day or less, and that includes files, manuals,
documents, clients, etc.
Thank you for your attention. Pardon me while I don my anti-flame suit.
--
Gene Dykes, gdykes@tcgould.tn.cornell.edubbadger@x102c.harris-atd.com (Badger BA 64810) (04/25/89)
In article <7798@batcomputer.tn.cornell.edu> gdykes@batcomputer.tn.cornell.edu (Gene Dykes) writes: [...] >Proposed Convention for Widget classname : IdClass > > "IdClass" : > "Class" : ambiguous. > "XidClass" : not concise; 'X' conveys no information ^^^^^^^^^^^^^^^^^^^^^^^^^^ > >Thank you for your attention. Pardon me while I don my anti-flame suit. >-- >Gene Dykes, gdykes@tcgould.tn.cornell.edu I disagree. X toolkits also have to operate with other non-X, perhaps non-graphical toolkits. The prefix 'X' helps prevent clashes there too. Bernard A. Badger Jr. 407/984-6385 |``Use the Source, Luke!'' Secure Computer Products |``Get a LIFE!'' -- J.H. Conway Harris GISD, Melbourne, FL 32902 |Buddy, can you paradigm? Internet: bbadger%x102c@trantor.harris-atd.com|'s/./&&/g' Tom sed expansively.
gdykes@batcomputer.tn.cornell.edu (Gene Dykes) (04/28/89)
In article <1967@trantor.harris-atd.com> bbadger@x102c.harris-atd.com Bernie Badger) writes: >> "XidClass" : not concise; 'X' conveys no information >I disagree. X toolkits also have to operate with other non-X, perhaps >non-graphical toolkits. The prefix 'X' helps prevent clashes there too. Actually, I think I agree with you. However, I thought it would be difficult enough to get a concensus just among Xt based toolkits that I left discussion of that aspect out. Adding an X to the widget class, using Xaw Label as an example, yields XAwLabel or XawLabel. This would make the nomenclature proposal much more consistent, since an X is prepended to other things like library names. -- Gene Dykes, gdykes@tcgould.tn.cornell.edu