Mike is DDJ's senior technical editor and can be reached at the DDJ offices or on CompuServe at 76703,4057.
Why was Motif designed the way it was? Is multiple inheritance really required to model real-world problems? What is software correctness and how can I incorporate it in my programming style? Questions like these represented the object (or more properly, object) d'art at the fifth Technology of Object-Oriented Languages and Systems (TOOLS) conference held recently at the University of California at Santa Barbara. In most cases, I found surprising answers to these (and other) questions, surprises that I'll share with you in this report.
The first two days of the conference offered a variety of tutorials split between a management track and a technical track. The last two days consisted of presented papers, panels, and a keynote address from object-oriented pioneer Adele Goldberg of ParcPlace Systems. One invited paper of note was presented by Vania Joloboff of OSF. Late afternoons were set aside for companies showing their wares.
Notably, the Eiffel tutorial was packed. A surprise, however, was that the C++ session given by Stanley Lippman, a technical staff member at AT&T and author of the well-known A C++ Primer, was not. And oddly, the CLOS tutorial received the least attention and was consequently canceled. (Nevertheless, it provided an opportunity for me to sit down with Lois Wolf of Franz, and chat about Lisp. From my school days, I've always thought of Lisp as a highly-recursive, function-based language. Lois's unique perspective as an in-the-trenches programmer in the early days at Symbolics provided some interesting insights on the development of Lisp dialects such as Flavors, Portable Common LOOPs, and CLOS. I hope Lois will share those insights with us in a future issue.)
The first thing to say about Eiffel is that it is not just a language, but a methodology. Developed by Bertrand Meyer, Eiffel embraces a notion of "software correctness" where the specification and implementation of a class exactly match. According to Meyer, a software component is written correctly if it adheres to a basic set of requirements. These requirements are encouraged by the language and selectively enforced at runtime. For example, Eiffel supports the notion of "assertions" as a means of rigorously specifying the features of a class. Assertions are Boolean values that involve preconditions which are required before a feature is executed; postconditions that are guaranteed to be TRUE after a feature is executed; and class invariants which specify properties that an instance must always satisfy. Including assertions in classes improves program documentation. But more importantly, they ensure the consistency of the class--a key factor to correctness. Also in the list of requirements for correct components are check-correctness, loop-correctness, and error-correctness. The idea is that together, these concepts allow you to create a specification of a class that is rigorous in nature, thus ensuring its correctness in design and implementation. (Also see "Writing Correct Software With Eiffel" by Bertrand Meyer, DDJ, December 1989.)
The development of Eiffel as a nonproprietary language is curious, to say the least. I was surprised at OOPSLA '90, when Meyer told me that the language specification had been placed in the public domain. Shortly thereafter, an independent organization was formed to maintain standards for various implementations of Eiffel, and to advance its cause. In March of this year, the Eiffel trademark, held by Meyer's Interactive Software Engineering (270 Stokes Road, Suite 7, Goleta, CA 93117), was passed to the Nonprofit International Consortium for Eiffel (P.O. Box 6884, Santa Barbara, CA 93160), which now monitors the language's standards. This is a first -- a nonproprietary language specification controlled by an "open" industry consortium!
These developments make it possible for independent developers to implement their own versions of the Eiffel language, and Eiffel/S is the first example of a commercially available implementation developed outside of Interactive Software Engineering (ISE). Eiffel/S, developed by SiG Computer, is a DOS version based on the Eiffel 3.0 specification (also a first). Interestingly, it can generate C source code that is compatible with either Microsoft or Turbo C. Note that Eiffel/S will be marketed in the U.S. by ISE; other planned versions include Unix V/386 and OS/2.
Another language, Sather, is based on Eiffel but departs from the specification in several areas. Sather, which currently runs on Sun 4 computers, places more emphasis on efficiency and less on "correct software construction." Sather was developed by Stephen M. Omohundro, who has also been involved in past developments of Star Lisp and Mathematica. Sather, which is currently in beta, is freely available through anonymous ftp, or on floppy disk or cartridge tape through Rock Solid Software (P.O. Box 163072, Austin, TX 78716). Sather is offered under a license agreement patterned after the Free Software Foundation's GNU license.
Windows is an event-driven system that is now accessible to object-oriented programmers using C++, Actor, Turbo Pascal, and the like. But although Windows supports message passing and subclassing of windows, it does not directly support object-oriented concepts.
Motif, on the other hand, is an exercise in object-oriented design using C. Motif, which is based on the X Consortiums Intrinsics Toolkit (Xt), uses Xt to provide object-oriented mechanisms such as encapsulation of window objects via widgets and single inheritance. According to Vania Joloboff, who is chiefly responsible for versions 1 and 2, a primary goal in designing Motif was to make it as close as possible (in terms of look and feel) to Windows. Although this makes sense, it is an interesting admission by Joloboff. There are a lot of DOS and Windows guys out there, and users can move freely from one environment to another. It also paves the way for multiplatform frameworks. (Maybe Al Stevens will add support for Motif in his next incarnation of D-Flat.)
Joloboff used Motif as an elegant example of the types of problems and decisions involved in object-oriented de sign. Subclassing, for instance, provides many benefits, including that of reusability. But when referencing an instance object in a large class hierarchy, the linker sucks in all code from parent objects and thus increases code size. Additionally, complex hierarchies increase program maintenance and the complexity of the documentation. So, the designer must decide at some point whether to subclass or augment existing classes.
There seems to be some debate in the object-oriented community over multiple inheritance. Opponents contend that multiple inheritance compounds the problems of subclassing (as described earlier) and introduces new problems such as name clashing and repeated inheritance. Both are usually handled by object-oriented language compilers, but keep in mind that Motif was written in C. The experts I spoke with, including Joloboff, feel that real-world modeling is not possible without the use of multiple inheritance.
I still see problems with this notion because I believe current mechanisms are not fully representative. Inheritance mechanisms as implemented in current object-oriented languages do not allow for features of a parent object to be selectively inherited. Selective inheritance is well known in the AI community, where links to nodes (objects) in the hierarchy can be distinguished as is-a (for example, float is-a real number) and a-kind-of (float is a-kind of number). But unlike their AI cousins, object-oriented inheritance hierarchies do not distinguish between the types of links in the tree. Child is-a-kind-of Parent. It's all or nothing.
Such semantics are quite possibly lost on the programmer trying to bang out the next killer app--just inherit the feature and ignore it. But aside from possible unwanted side-effects, there are performance issues. The decision in Motif, then, was to go with traits, or what Joloboff calls a "poor man's multiple inheritance." Traits are methods, such as PUSHABLE, which can be applied to objects. An interesting solution.
Hearing Adele Goldberg at the podium was itself worth the price of admission. Goldberg's talk on the "need to change" inspired many attendees to rethink their strategies for management, structuring of programming teams, and the role of consultants. A recurring theme at the conference (which surfaced in Goldberg's address) was that of a new reward system for programmers. The current system is to reward programmers for the number of lines of code they produce. I'm all for reward, but that's at odds with the desire to reuse code. (Think about that when you ask for your next raise.)
Noting the high levels of hype in the industry, Goldberg warned that the AI community also enjoyed its moment in the sun and that (the industry) is not doing any favors by over-promoting the technology. Indeed, many of us (even editors and journalists) have hopped onto the object-oriented wagon. The discussion, however, implied that many products are claiming to have object-oriented features merely to gain its benefits, alluding to Pascal as a case in point.
Both Microsoft and Borland have provided extensions, based in part on Apple's Object Pascal. I caught up with Borland's Eugene Wang to get his take on the comment. According to Wang, "Turbo Pascal provides three levels of object-orientation: the language, supporting tools, and application frame-works." Wang is quick to point out that the syntax of the language supports encapsulation, inheritance, and polymorphism and notes that Turbo comes with a browser and object inspector integrated with Turbo Debugger.
When asked for a show of hands, about half the keynote audience admitted they were at least familiar with application frameworks, which provide a high-level layer between the programmer and the operating environment. Indeed, the proliferation of GUIs will make application frameworks the new front for compiler vendors. Witness the heavy investments in the technology by companies such as ParcPlace and Borland.
Turbo Pascal, for example, provides application frameworks for both DOS (with Turbo Vision) and Windows (with its Object Windows Library). I've used Object Windows, and there's a significant learning curve associated with it. As you might guess, mastering the hierarchy and knowing when (and how) to make calls directly to the Windows API takes time. But there are a number of fine points that creep in. For instance, Turbo Pascal now supports null-terminated strings, which are required by Windows, both as PChars and zero-based character arrays. These are handled in different ways and are a source of confusion among programmers used to Turbo's String type. Turbo provides a set of functions for handling PChars, but no checking is performed by these functions. This leads to problems, such as dangling pointers, seen only in languages like C. I'm not sold on the benefits for users of Turbo Vision, but the investment is definitely worth the time for Windows programmers.
Questions I did not hear at TOOLS were, "What are the benefits of object-oriented programming?" or "What is inheritance?" For the most part, the attendees were a sophisticated group with an advanced understanding of object-oriented principles. The presentations were small and informal, making some of the top experts accessible to all. Also, the emphasis seemed to be less academic with more focus on applications and practitioners. As noted by Bertrand Meyer, TOOLS caters to the attendees--not just the presenters.
Meyer also noted that holding conferences more frequently enables organizers to react more quickly to industry developments. In fact, TOOLS will be held three times next year, starting with a Sidney, Australia session in December and a March '92 conference in Dortmund, Germany. I suppose I'll have to wait for the next conference in Santa Barbara, but there's no question it'll be worth the wait.
Copyright © 1991, Dr. Dobb's Journal