Columns
A Letter to the Editor: Taking issue
I read [Uche Ogbuji's] article [ "Objects. Encapsulation. XML?," ADT, Dec. 2003, p. 20] with some interest -- I've been an OO programmer for years (C++ and Java, with some Python) and also use XML (so I never have to write another parser in my life).
I take issue with polymorphism as the main tool for the matching of semantics. Polymorphism is probably the least important of the three main traits of OO languages; polymorphism causes decreases in reuse due to undesired side-effects and the lack of "componentization" of the result.
Your cheap shot about Java not being an OO language is interesting. Do you think Eiffel is object oriented? The only thing Java has going against it in OO-land is the availability of primitives -- and those are included for performance reasons.
XML is much more object oriented than relational; mapping XML to relational databases requires careful thought or specialized software (for example JDO and the J2EE's container-managed persistence). The first XML databases were OO databases that had an XML front end grafted on. XML is designed for "has-a" relationships and less for "is-a" relationships -- this actually makes it a better meta-language for building reusable data components.
The right question to ask around programming models is, "What will allow me to understand and build the biggest, best systems for the least cost?" That is where the value is in programming today, and that's why OO style efforts are still leading the way, with aspect-oriented tools coming alongside to provide breadth vs. depth programming styles and problems; that's also why there will always be other paradigms for solving problems in the software industry.
--Bob Hays
[email protected]
Uche Ogbuji's reply:
I have also been an OO programmer for years -- C++ since 1992, Java since 1997. I've also worked with Smalltalk, Python, Objective C, CLOS and a touch of Eiffel. OO is my background.
Polymorphism does not have any implicit proclivity to side-effects. It's the implementation in C++ (and similarly implemented in Java and C#) that causes this. Polymorphism is implicitly declarative, and so the idea itself is actually somewhat antithetical to side-effects.
I make the claim I do because I believe that practical adaptation of static, strongly typed code requires late binding, and the limited polymorphism based on double indirection of function pointers is really the only available mechanism in C++ and like languages. If you break down to plain old C, you actually gain a great deal of power in implementing late binding, which is one of the reasons I've come to believe the C++ generation of languages took the high road straight off a cliff.
I said: "Most languages that we think of as OO these days are just procedural languages with some OO scaffolding on top. (Yes, even Java and C#, which were supposedly designed to be fresh, clean and OO to the core.)"
I'm not sure why you consider this a cheap shot. The OO mechanism in all these languages is very high level. The languages follow the imperative model of control flow and really only recognize the nature of objects and methods during function dispatch. Even during compile-time checking they are just marshalling abstract data types.
You ask whether I think Eiffel is object oriented. I'd say that Smalltalk and CLOS are better examples. Objective C, Eiffel and even my favorite Python are more OO than the C++ generation, but also mostly imperative languages at the core. The nice thing about Python is that its dynamicism provides for richer OO expression than Objective C, Eiffel, C++, Java or C#. As an example, you can pretty easily arrange for polymorphism to operate without side-effects in Python.
As for the split between primitive data typers (such as int in Java) and their polymorphic equivalents (such as Integer), this sort of thing should have been taken care of through a smart optimizer, not through the ugly contortions Java perpetrated. The Squeak implementation of Smalltalk might have been a decent model; many aspects of its handling of primitives are very clever and powerful. As another example, C++ has undergone titanic struggles to try to balance the fundamental concept of the character pointer/reference with the need for an OO String class. But I think the results in both C++ and Java cause more violence to tidiness and simplicity than to basic OO principles.
I've worked on XML bindings to OODBMS and RDBMS, and I don't see that mapping XML to RDBMS requires any more care than mapping to objects. Java data bindings, for example, are pretty unsightly things and I don't think they are any more elegant than, say, SQLX (which is, unfortunately, not very elegant in the first place).
One of the pioneering "native" XML DBMSs, Excelon, was indeed little more than wrappering of an OODBMS (ObjectStore), but I don't think that has given it any particular technical or marketing edge. Other non-relational DBMSs that morphed into XML DBMSs were often from pre-OO roots: Adabas became Tamino, Pick became Raining Data and so on. But relational juggernauts such as Oracle and IBM/DB2 have never been slouches in XML either, and are showing no signs whatsoever of falling behind in the stakes; in fact, quite the contrary. I don't think there is a good technical argument that it makes any particularly good sense to create an XML DBMS by tweaking an OODBMS, and I have been badly burned in the past by trying to import too much of an OO mindset into XML technology.
XML does not fundamentally recognize any of the classic OO relationships. The data model of XML is labeled Unicode strings. Even when elaborated into the fancy Infoset it is still effectively just strings with simple string properties. You can drape on the idea of has-a relationships (nested elements), but you can just as easily drape on is-a (element type extension through parameter entities is strikingly similar to the implementation of C++ inheritance in the pioneering AT&T Cfront compiler) or "object" reference (id/idref).
Finally, I do agree that Aspect-Oriented Programming (AOP) is perhaps the best hope there is of reforming the current mainstream in OO languages. AOP mixes in a much-needed declarative bent to the imperative OO mainstream, and I hope AOP folks find success broadening programmers' vision as to how to bind behaviors to objects. I can't resist pointing out that the very idea of AOP is intuitive in languages such as Python, and requires very little additional scaffolding.