guido@cwi.nl (Guido van Rossum) (04/30/88)
In article <8804281342.AA01954@LYRE.MIT.EDU> swick@ATHENA.MIT.EDU (Ralph R. Swick) writes: >[...] but the real bug in your >test case was incorrectly typing the resource variable. String resources >are always passed as pointers. The following mods make your example work: >[...some lines deleted...] >static XtResource resources[] = { > { "display", "Display", XtRString, sizeof(char *), (Cardinal)&display, > XtRString, NULL }, >}; Although I know that "the" [* see footnote] X Toolkit makes a programmer's life much easier compared to using raw Xlib, this example clearly illustrates some of the problems I have with it. We see here a data initialization as is customary in widget creation code. I find it ugly. Why is it so ugly? And why was there a bug in the program Ralph was replying to? Because the typechecking is almost completely defeated. Because of the way these things have to be filled in, the C compiler has no way to check the types of parameters passed to widgets. That's the price you pay for having one, very general way of passingparameters to the universal widget creation routine. Another reason why it is ugly is the longish prefixes needed for constants defining conceptually simple values like XtRString (and there are worse examples, e.g., XrmoptionSepArg). Here the problem is one of name space: conceptually you want a separate name space for each such option field, however, since C does not have such a language feature, the identifiers are made unique by prefixing them with something. I can imagine that a preprocessor be built which takes a definition of a widget in a more understandable and more checkable language, more tailored to the definition of widgets. Such a language should know the set of parameters that a particular widget type accepts, their types, whether they are required, default values, etc. We could also pick an existing language like C++, where I believe much of the flexibility of the toolkit can be reached by redoing widget classes as C++ classes and subclasses. Callback functions could be done with virtual functions; to substitute a callback function of your own invention all you need to do is define a derived class which overrides one or more virtual functions of the base class. This gives you more flexible parameter types to the callback functions as well (with typechecking!). I suppose the limited 'default parameter' feature of C++ is too weak to handle the large number of overridable defaults on the average widget, but still... What this buys us is more static typechecking of widget-using code, and smaller and faster code because everything the compiler can figure out doesn't have to be done at runtime (e.g., looking up strings in argument lists, mapping function names back to function addresses, etc.). You might read this as an advise to the C++ world not to create an interface to the X toolkit (LOTS of header files to translate...), but rather to create a completely new toolkit, more in the style of C++. --Guido [* promised footnote]: "The" toolkit should have a more distinctive name, just like the accompanying widget set is now called "Athena Widgets". There can and will be other toolkits, which will have to fight for their rights as first-grade citizens. I don't mean other widget sets. I mean other toolkits with radically different approaches, perhaps different architectural models. -- Guido van Rossum, Centre for Mathematics and Computer Science (CWI), Amsterdam guido@piring.cwi.nl or mcvax!piring!guido or guido%piring.cwi.nl@uunet.uu.net
vlis@Shasta.STANFORD.EDU (John Vlissides) (05/01/88)
You might be interested in checking out InterViews, a C++ toolkit with functionality comparable to the X Toolkit's. Version 2.3 is on the X11R2 distribution. You can send questions/comments about InterViews either to me or to linton@lurch.stanford.edu. John Vlissides Center for Integrated Systems, Stanford University vlis@aurora.stanford.edu