From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.object
Subject: details on terminology (Re: comparing object-oriented platforms)
Date: 13 Oct 92 02:29:18 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

Now, I have little hope that the confusions about terminology can be
stopped, but let me at least make an attempt.

Also, please note that when I say "OO" I mean "inheritance + classes"
only. There are lots of other features that "OO languages" have, but
they are not _specific_ to OO languages. If your terminology is
different, fine, but for my posting, I will use the terminology I have
learned...

objsys@netcom.com writes (or quotes...):
>I don't think so.  You [who? not me!] claimed that OO polymorphism is
>Ad Hoc, and this is simply not true.  [...]  I think you miss the
>point.  I've discussed adding dynamic typing to static type systems
>myself but this is an idiom and shows that static typing can emulate
>but is not as powerful as dynamic typing (or you wouldn't need to
>emulate it).

There are several kinds of approaches to typing and to "polymorphism"
that are in common use:

(1) overloading or ad-hoc polymorphism
(2) OO polymorphism (inheritance-based polymorphism)
(3) Milner style polymorphism ("parametric polymorphism")
(4) parameterized module systems
(5) dynamic typing

Now, these are all different, and they all have different implications
for code reuse. There are several observations I wish to make.

(a) You do _not_ need dynamic typing in order to have OO polymorphism.
As C++ amply demonstrates, having OO polymorphism (i.e., being able to
pass a derived object instead of an object belonging to the base
class) is not in itself sufficient to determine the type of the object
passed. Or, if you want to express it the other way around, you don't
need to know the type of an object in order to perform dynamic method
dispatch for it.

(b) Many OO languages (e.g., Smalltalk, Eiffel, CLOS) give you dynamic
typing _in addition to_ OO polymorphism. The reason is that with OO
polymorphism alone (i.e., no downcasting), you cannot write useful
functions that operate on general collections. On the other hand, if
you want a feature like downcasting or reverse assignment to detect
type errors at runtime, you need to keep more type information.

(c) Several other OO languages (e.g., C++, Eiffel (?)) give you some
form of genericity or even something akin to Milner-style
polymorphism, for the same reason as (b): without such a feature, you
would need downcasts or code duplication in order to express many
kinds of useful functions.

(d) The principal goal of OO polymorphism is presumably to be able to
reuse code written in terms of one type without change with objects of
another type. While support from the type system may be notationally
convenient for this, it is in general not necessary, even in
statically typed monomorphic languages if your language supports
closures. That is, you can reuse (properly written) old functions
written in terms of some new type with arbitrary, semantically
compatible newly defined types; you do not need inheritance to make
this work, and you do not any kinds of unsafe type conversions.

So, in summary, I stand by my claim that from the point of code-reuse,
type safety, and encapsulation, you do not need specific language
support for OO polymorphism (or overloading) in languages with
closures; OO polymorphism and overloading are mere notational
conveniences. (The popular retort to a statement like this is "well,
all programming languages are notational conveniences for Turing
machines". My claim is stronger, since I'm talking about a statically
typed language and consider issues such as code duplication and
encapsulation. A TM version of some program has no static type
checking...).

Milner-style polymorphism and parameterized module systems, on the
other hand, give you genuine potential for code reuse that you
wouldn't get without it. In my experience, of those two, Milner-style
polymorphism (somewhat like C++ template _functions_) is more
convenient for programming in the small, while parameterized module
systems (somewhat like C++ template _classes_) are more convenient for
programming in the large and also somewhat more powerful.

In any case, I realize that I haven't repeated my examples or detailed
explanations for claims (a-d) above; you will either have to search
for the old articles that I posted or wait until (if ever) I get
around to writing a memo on this.

					Thomas.

Newsgroups: comp.object