Re: PL/I Versus Ada (Was: Arianne ...)

["Lon D. Gowen, Ph.D." <gowen@microware.com>]

Richard Riehle wrote:
> 
> On 21 Aug 1996, Tony Konashenok wrote:
> 
> > What exactly is an "object-oriented version" of a language? Why is PL/I
> > not object-oriented? IMHO, one can do object-oriented programming even in
> > assembly language, given enough skill and dedication. Too many people are
> > confusing object-oriented programming as a method with the usage of
> > C++/Ada-specific features.
> 
>   Well you may have your own idea of object-oriented programming.
>   We usually think of encapsulated classes which support extensible
>   inheritance, dynamic binding, and polymorphism.  We ordinarily do not
>   consider the heroic efforts of a star programmer as being sufficient
>   to implement the method.  There are specific, widely-accepted criteria
>   for object-oriented programming which are not language-specific.
>   So I will rephrase the question.

Well, now that poor Tony is ducking arrows from Richard, allow me to take
a few arrows.  Tony is correct in a sense.  A coder can do OOP without
using an OOP language such as C++, Ada 95, etc. (see "Software Engineering"
by Ian Sommerville, which is a well-known text on SE ideas).  However,
using an OOP language does make the coding of an OOD easier.

The beginning of OOP came from SIMULA 67; however, no one ever made this
connection until Hoare did in 1972.  The basic tenants of OOP go back to
its originator SIMULA 67, and they basically focus around the ideas of
the "class construct," which allowed a person to keep a data structure
and its associated routines packaged together (i.e., data abstraction).
Unfortunately, SIMULA 67 did not have "information hiding" (i.e., the
inforcement of abstractions; or, put another way, multiple-access
paths to data types).

One of the big (supposed) benifits and one of the most important
components of OOD/OOP is this idea of data abstraction.  All languages
(even assembly languages) can support data abstraction (and, therefore,
functional abstraction too).  Additionally, there are various levels of
data abstraction (e.g., all high-level languages--HLLs--use simple data
abstractions such as their builtin abilities to manipulate integers,
reals, strings, etc.).

OOP uses the ideas of data abstraction; and data abstraction, by definition,
includes encapsulation (i.e., the ability to group data or operations into
separate syntactic containers), functional abstraction, and sometimes
information hiding.  There are various groups of OOPLs, which we can break
up into two main groups:  pure OOPLs (e.g., smalltalk and Eiffel) and
hybrid OOPLs (e.g., C++ and Ada 95).  Generally speaking, an OOPL has the
following "features":  data abstraction, inheritance, and a particular
type of dynamic binding (i.e., a kind of polymorphism).  The purpose of
inheritance is to facilitate the reuse of abstract data types (ADTs).  And,
reuse is supposedly beneficial to software development efforts.  Therefore,
the big attraction to OOP is through the supposed improvements of ADTs,
dynamic binding of requests, and inheritance.

The information above comes from Bob's book on programming languages
(see "Concepts of Programming Languages" by Robert W. Sebesta, third
edition).  By the way, Bob Sebesta currently chairs the computer science
department at the University of Colorado at Colorado Springs:  At least
he was still there when I had dinner with him this Spring.  As a side
not on this whole issue, Chapter 10 (on Abstract Data Types) of Bob's
book begins with a picture of George Radin, who (as the book states)
"was one of the principal designers of both the PL/I language and IBM's
first compiler for PL/I"--kind of ironic :-)

> 
>   Is there a version of PL/I which:
> 
>      1) has explicit syntactic support for extensible inheritance
>         of encapsulated classes (i. e., supports Meyer's "open/closed
>         principle") ?

You can implement inheritance in PL/I (see prior articles regarding a
white paper by Smedley and Smith).  Most (if not all) PL/I compilers,
however, do not come with the proper libraries to facilitate it.

> 
>      2) supports dynamic selection of class object based on run-time
>         evaluation of class membership  (dynamic binding and
>         polymorphism)?

You can also support dynamic binding in PL/I of just about anything
including classes.  Once again, see the white paper by Smedley and
Smith.  Remember, PL/I's pointers are untyped, which means extreme
flexibility (and usually a decrease in reliability).

> 
>      3) permits the definition of a type/class with hidden data
>         structures that are visible only via their exported
>         methods?  (a la "programming by contract")?

This concept is information hiding and not necessary to do OOP.  The main
benefit of IH is to keep programmers from gaining access to an item
without following the proper channels.  IH is a "big brother" (liberal)
concept that programming in general could live without.

> 
>      4) allows the definition of "abstract classes" (deferred classes)
>         for implementation, through extensible inheritance and
>         polymorphism, of variants of that class.  This should include
>         the capability for late binding?

Again, I see no problems here.  Once again, you would have to build in
the features yourself or borrow (or buy) the ideas from someone else.

> 
>    None of these characteristics are language-specific, but each is
>    included in any language defined, by contemporary usage, as an
>    object-oriented programming language.  How does PL/I compare?
> 
>    Richard Riehle

The designers of PL/I wanted it to cover everything, and it pretty
much fulfills their expectations.  Depending on how you view
things, PL/I does support OOP; however, you have to do a little
work beforehand to make life consistent and easy.

Lon

-- 
Lon D. Gowen, Ph.D.
Phone:      (515) 223-8000 x217         Fax:  (515) 224-1352
e-mail:     gowen@microware.com         WWW:  www.microware.com
U.S. Mail:  Microware Systems Corporation
            Research & Development Department for Core Technologies
            1900 N.W. 114th Street
            Des Moines, IA 50325-7077

Disclaimer: All opinions are mine and not necessarily those of anyone else.

"Only when we have built a similar system before is it easy to determine the
requirements in advance."  --David L. Parnas