Letters

Larry Martin

[email protected]

Eugene responds: Glad you enjoyed the article, Larry. You can find additional information at http://extende.sourceforge.net/ and http://sds.sourceforge.net/. The first site contains the paper written by Eric Armstrong, which I cited in my article.

Passing the C++ Test

Dear DDJ,

I [read] Al Stevens's article "Passing the C++ Test" (http://www.ddj.com/articles/1998/9813//documents/ddj9813d/) and he has probably received many responses since its initial publishing, but somebody posted a link to it on comp.lang.c++.moderated, and I couldn't help but respond to you about one of the questions/answers.

Q: When should you use multiple inheritance?

A: There are three acceptable answers: "Never," "Rarely," and "The problem domain cannot be accurately modeled any other way."

I find this answer hardly satisfactory, but probably not for the reason you would first think. I'm not a fan of the typical type of multiple inheritance that many C++ programmers try to defend. However, multiple inheritance is a great feature that can be used often if (99 percent of the time) it is restricted to a special form called multiple "interface" inheritance. If you are only inheriting from interfaces (abstract classes in C++), you don't have to worry about the typical "diamond of death" problems. And unlike your statement:

Stress this understanding because your interviewer might share the common bias against multiple inheritance that many object-oriented designers hold

I believe that most (if not all) competent practitioners of OOP advocate this philosophy of design. As an example, the designers of the Java language felt that interface inheritance was such an important feature of OOP that they introduced a specific keyword into their language to support it (interface). In addition, Java programs support multiple inheritance, but only multiple interface inheritance.

As another example, I would cite Smalltalk, which [not] only allows single implementation inheritance, but allows any object that supports an "interface" to be used as that interface. For example (my Smalltalk is extremely rusty so this is more like pseudocode than Smalltalk), given:

aMethod( /* Notice no type is specified here */ aContainer ) {

aContainer getSize

}

Any object that has the method getSize can be passed as an argument to this method. So, in Smalltalk, you can "virtually" multiply inherit by having a single object implement many "interfaces" (by simply implementing the union of all the methods belonging to the set of interfaces).

This same sort of "typeless interface inheritance" also exists in Lisp. (If you are unfamiliar with Lisp, specifically, I'm speaking about Common Lisp Object System (CLOS), which is an OOP package built into ANSI Common Lisp).

In summary, Multiple (Interface) Inheritance is A Good Thing, and is supported in many languages. Multiple (Implementation) Inheritance is not so good (99 percent of the time), and is, not surprisingly, not supported in many languages. Software engineers that practice OOP should understand this.

Toby Reyelts

[email protected]

Al responds: Toby, many thanks for your comments. I am a fan of the interface model of MI when the language supports and encourages it separate from what you call multiple (implementation) inheritance as Java does. I am not a fan of programming idioms that use existing language features in ways that do not immediately convey their intent and meaning to the casual reader.

Since templates were introduced I've found little use for MI in C++. I do, however, often make the argument that when a design must accurately reflect its problem domain, sometimes MI is the only mechanism for the expression of that design. An asset is one thing; a vehicle is another; some vehicles are assets; some vehicles are leased and are not assets; all assets are not vehicles; and so on. Whether this argument addresses only 1 percent of the possible uses of MI, I cannot say.

Ruby, Ruby

Dear DDJ,

Dave Thomas and Andy Hunt's article on Ruby ("Programming In Ruby," DDJ, January 2001) got me wondering if anyone outside of the Big Blue mainframe crowd and certain OS/2 bigots knows about REXX?

Before retirement, I spent my time programming using REXX and found it to be the easiest language (for me) to master. I used it for prototyping and proving concept for many of my projects.

Now REXX has grown to become Object REXX and NetRexx, and is no longer restricted to the mainframe world. I'm using OOREXX on my NT with good results and I use the object-oriented parts that I wish, implementing as I desire.

Though I have not worked with NetRexx yet, it appears to be a good alternate to Java — and may even be preferred over learning Java. I am fascinated with the claim that NetRexx does the same thing as Java with 30 percent fewer keystrokes, and its output is Java byte code, and it uses all the Java classes, and runs in the Java environment.

More can be found on http://www.rexxla.org/. While the major downside in using REXX versus Ruby may be the price...

Rob Chamberlin

[email protected]

PHP and Hosted Applications

Dear DDJ,

I read Ahmad Abualsamid's "PHP & Hosted Applications" (DDJ, January 2001) with great interest, since I'm putting the finishing touches on an application that I've been building — Ultimate.asp — which not only allows complete management of all the Access databases on the server/machine, but with a single click, will also dynamically generate a complete administrative application for an Access database. I've also given it the ability to dynamically generate .asp pages for any successful select query of any of the Access databases. Anyway, I wrote an ASP version of Ahmad Abualsamid's PHP application. For anyone interested, it's at http://www6.ewebcity.com/mbrink1111/survey.zip.

Michael Brinkley

[email protected]

Shared Libraries Aren't All Bad

Dear DDJ,

I take exception to Jeff Duntemann's view that "[t]he worst idea ever to arise in the history of computing is shared code libraries" ("Most Significant Event," DDJ, January 2001). While it may well be true that DDLs (or DLL misuse) are in a narrow sense responsible for most Windows stability problems, that is not because of any problem inherent in the concept of shared code libraries. It's due to poor shared library design by Microsoft (particularly the lack of an effective versioning mechanism), and extremely poor shared library hygiene, both directly by Microsoft (which likes to release incompatible revisions of major system DLLs) and indirectly (in encouraging third parties to ship and install incompatible versions of system DLLs).

Many other operating systems have shared library implementations that work just fine. Among UNIX flavors are the System V-based designs used by, for example, Solaris and Linux, and the proprietary ones found in AIX and HP-UX. These work so well that during the Linux transition to glibc, it was common for Linux systems to have installed at least two completely incompatible C run-time libraries; applications used the one they needed, transparently to users. Then there are various shared library designs that are radically different, like the srvpgm objects in OS/400. They also perform their functions without rendering the OS unstable.

While 30-GB hard drives may be relatively cheap for desktop PCs, some computers have more stringent requirements that aren't as easily satisfied by bottom-of-the-barrel commodity components. And many of us aren't inclined to try to upgrade perfectly useful computers that don't have cheap 30-GB drives available. But disk storage space savings are not the only reason for shared code libraries; they're not even a primary one. Far more important are, for example, the sharing of text pages in shared libraries, greatly reducing the memory footprint of applications (should we all have 30 GB of RAM, too?); the ability to fix library problems or extend functionality across all applications by upgrading the shared library (a quick review of the CERT or BUGTRAQ archives should demonstrate just how important this is); and the ability to extend program function without recompiling it through dynamic code loading. Not all of computing is Windows, and Windows isn't even a good example of how Windows itself should have been implemented.

Michael Wojcik

[email protected]

Jeff responds: Okay, let me get this straight: You want DLLs (and all the inherent danger in their misimplementation and abuse) so that some small number of backward-looking machines can continue to limp along with 100-MB disk drives and 10 MB of RAM. That sounds like a lousy cost/benefits ratio to me. My blinkers keep me focused on what I need to get my work done: A desktop environment and applications that don't waste my time. Right now, that's Windows. I'd love the stability of Linux and the usability of Windows. Who'll give it to me? I'm getting pretty tired of waiting for it, to be honest with you. It pains me to say it, but unless the industry quits whining and presents a viable competitor to Windows, computing will soon consist of Windows and PalmOS, plus debris. In a world like that, DLLs should give everybody the cold sweats, because Windows is everywhere, and DLLs are why Windows doesn't work.

DDJ