Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!samsung!think!ames!ncar!boulder!gore!jacob
From: jacob@gore.com (Jacob Gore)
Newsgroups: comp.object
Subject: Re: Evaluating "Object-Oriented" Programming Languages
Message-ID: <1130004@gore.com>
Date: 4 Jan 90 01:05:57 GMT
References: <638@ajpo.sei.cmu.edu>
Reply-To: jacob@gore.com (Jacob Gore)
Organization: Gore Enterprises
Lines: 67

/ comp.object / eberard@ajpo.sei.cmu.edu (Edward Berard) / Jan  2, 1990 /
> As part of the
> evaluation of any candidate language for object-oriented software
> engineering, I propose that three main questions be asked [...]

I would add a subquestion to each of these:

	Are the features under consideration easy and natural to use
	in the languages being compared, or does the programmer have
	to go through a lot of effort to make use of them?

In the case of Ada, one example of "a lot of effort" is when programmers
use task types to implement classes of objects that have nothing to do with
concurrency, because package types, the natural thing to use for the
problem at hand, are lacking in the language.

> 	- Under the category of features that Ada lacks in comparison
> 	  with most object-oriented programming languages we have, for
> 	  example:
[...]
> 		- dynamic binding: Ada's emphasis on reliability
> 		  shifts part of the burden to the programming
> 		  language itself. In languages which feature dynamic
> 		  binding (e.g., Objective-C ([Cox, 1986])), the onus
> 		  is more on the software engineer, and less on the
> 		  language, in terms of reliability. Therefore,
> 		  dynamic binding is an attribute which directly
> 		  conflicts with the original intentions of the Ada
> 		  language.

Are these goals truly conflicting?  I don't think so.  Dynamic binding need
not be unconstrained, and it need not be done at the expense of static
typing.

Some of the common O-O languages (e.g., C++, Eiffel, and even the current
version of Objective-C) take advantage of the concept of subtyping for
this: generally speaking, an operation taking an object of type T as a
parameter will also accept an object of any type T' which is a subtype of
T.  The assumption is that whatever can be safely done to an instance of T
can also be safely done to an instance of T'.  Is this assumption
inconsistent with Ada's ways of emphasizing reliability?  (This, of course,
cannot be done in Ada-83 since it does not provide a syntactic (for the
benefit of the compiler, as well as the programmer) way to create subtypes
of user-defined types.  ...Well, maybe it can be done, but not in a
straight-forward manner.)

>		  ... Not all Ada objects are first-class objects.

That, in my view, is the biggest problem.  Not just with Ada, and not just
concerning object-oriented programming.  I hate it when there are things in
a language that can be done with predefined types but not with
programmer-defined types.  For example (I'm not talking about Ada
specifically), when only predefined types can be initialized and finalized.
Or when you can have arrays of INTEGERs, but not of SQUIRRELs.  Or when the
"+" in "A+B" can be overloaded for predefined types, but not for
programer-defined types.  Or when there is a group of "standard" functions
that take a variable number of parameters, but the programmer has no way to
define such a function.

An object-oriented language, first and foremost, should make it easy and
natural to define and use objects.  This means that all objects --
programmer-defined and language-defined -- should be first class entities
in the language.

Jacob
--
Jacob Gore		Jacob@Gore.Com			boulder!gore!jacob