From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.object
Subject: alternatives to "strict OO"? (Re: comparing object-oriented platforms)
Date: 13 Oct 92 02:11:17 GMT
	<TMB.92Oct11222217@arolla.idiap.ch> <1992Oct12.004546.27003@netcom.com>
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: objsys@netcom.com's message of 12 Oct 92 00:45:46 GMT

In article <1992Oct12.004546.27003@netcom.com> objsys@netcom.com (Bob Hathaway) writes:
>I've used generics for so long (starting with object-based languages) that
>I consider them an integral part of and principle reason for OO.  Perhaps
>you're interpreting OO as strict inheritance and nothing else?

In that case, the term "OOP" apparently has become meaningless, since
it has come to mean "anything that is good about programming in terms
of ADT's". So, let me use the term "strict OO" to refer specifically
to the "inheritance/class" framework used by OOP for organizing
datatypes and operations on them.

The main point I have been trying to get across in my postings is that
I consider the inheritance/class framework in which "strict OOP" is
couched harmful, since it fails to address several important problems
in programming in terms of ADT's (I have given several examples on
this list). As far as I can tell, some of these problems are intrinsic
to the inheritance/class framework, since there are many kinds of
relationships among ADT's that cannot be expressed mathematically in
terms of a hierarchy.

The approach that most "programming language designers" seem to have
used to cope with these problems has been to offer a patchwork of
workarounds like "multiple inheritance", "reverse assignment",
"dynamic typing", "multiple dispatch", "templates", "generic module
systems" etc. But (except for features like templates) these features
(as I think, unnecessarily) create the potential for runtime type
errors. The result is cumbersome, complicated, unsafe tools that make
everybody's work harder (including my own work).

What I hope to achieve is to get more people to consider alternatives
to the "strict OO" paradigm.

Now, the functionality that "strict OO" provides is useful, and if we
give up the "strict OO" framework, we have to provide some substitute.
The functionality that I'm talking about is to be able to reuse code
with any data type that adheres to a specific protocol (a slightly
more general definition of "OO polymorphism"). What I have argued
before on this list, this is possible without inheritance even in
monomorphic statically typed languages _if_ you have closures. So,
apart from some notational conveniences, there is no specific type
system support we need for "OO polymorphism" in the presence of
closures.

One alternative to the "strict OO" paradigm that I see is the
combination of features offered by the SML language. SML is statically
typed (with Milner-style polymorphism), and it offers a powerful
module system. I don't want to claim that the language is perfect--it
clearly has its problems (both syntactic and semantic). But, I have
found that the combination of language features that it offers
addresses most of the software reuse problems that I see within a
"strict OO" paradigm. In different words, the kind of reuse and
abstraction that you can express in SML (using closures, Milner-style
polymorphism, and its module system) is superset of what you can
achieve in languages like C++ or Eiffel, while at the same time
guaranteeing static type correctness.

Since I need to write real-world, large, safe, reusable software
packages, I would like to see more language development and
implementation go more in that direction, rather than this almost
blind tinkering with features within the "strict OO" dogma.

It's becoming clear that in order to convince more people on the OO
side of this view, it is really necessary that I write up a real paper
that addresses all these claims and considerations in a single
document, rather than scattering them across lots of postings. I had
always assumed that lots of people actually knew about the
relationships between type systems, closures, and OO polymorphism that
I have outlined above, but apparently I was mistaken.

					Thomas.