🚀 go-pugleaf

>> by me (Ralph Johnson)
>  by Bill Wolfe

>    (Note for readers unfamiliar with the terminology: "class" 
>     is New-Speak for "type", and "method" is New-Speak for 
>     "procedure or function"...)
Class and type are not necessarily the same.  Languages like C++
make them the same, but I think that is a mistake.  It certainly
is not true in Smalltalk or Lisp-based languages.  Class doesn't
mean type any more than it means package or module (which I have
seen people claim).  Methods and procedures are almost the same,
except for the polymorphism induced by run-time binding of procedure
calls.

Also, Smalltalk predates Ada, so "New-Speak" is not appropriate.
OOP maybe cultish or insular, but it is not new.

>> This style of programming results in ugly class hierarchies and 
>> can lead to the inefficiencies that Bill Wolfe complained about.  
>> However, it is very valuable during rapid-prototyping and helps 
>> lead to families of interchangeable components.  

>    My comments specifically indicated that the tactic may be useful
>    in isolated areas in which development costs were important and
>    utilization costs were not; however, this does not characterize
>    the software components marketplace.

I'm not concerned about the component builders as much as the component
users.  Building an application is often similar to rapid-prototyping,
because when you show it to your customer you find out that you were
being misinformed when you did the requirments analysis.  Further, the
most important kinds of components are application specific, and so I
expect that each company will continue to develop its own components, 
in addition to using a large supply of components developed outside.

>> The third way of using inheritance is to inherit from an abstract 
>> class, also called a deferred class.  This is the most elegant use 
>> of inheritance, and is essentially using the superclass as a template 
>> to generate new classes.  

>    By this I presume you mean the inheritance of specifications;
>    if not, be precise.

No.  An abstract class is a class with some methods left undefined.
Thus, it is not possible to make objects from it, only to make subclasses.
The subclasses must define the undefined methods.

That is as precise as I can get.  It's pretty hard for someone who hasn't
done any object-oriented programming to understand the ramifications of it.
Abstract classes are a lot like using a generic package that is parameterized
by a set of procedures.  One big advantage of object-oriented programming
is that superclasses can provide default implementations of methods.  In
fact, you can look upon a class as a generic package that is parameterized
by ALL its procedures, since a subclass can redefine any of the methods
that it is inheriting.

>> We need to make software easier to change.  

>   By constructing software in a modular manner.

Modular software is good, but not enough.  Inheritance lets you
modify components that are not quite right.  Object-oriented programming
certainly promotes modularity, but it also promotes abstraction and
classification of families of similar components.  These are just
as important.

>> In fact, most software that is written is run on only a few machines.  
>> Few programmers are writing software that will run on thousands of machines.

>   Oh, but I beg to differ.  A large and rapidly growing number of
>   programmers are writing software in Ada, a language which is
>   rigorously standardized, allowing one to write software which
>   will run on any machine having a validated Ada compiler.  This
>   amounts to millions of machines.  In fact, without this level 
>   of standardization, it is difficult to imagine a viable software 
>   components industry.

I didn't say "COULD run on thousands of machines".  Lots of languages
let programmers produce portable code.  The fact is, most programmers
are application programmers, and that will continue to be true.
Object-oriented programming is good because it makes THEIR life
easier, not just the component developer.

I am a great fan of software components.  All object-oriented programmers
are.  I believe that object-oriented programming is the best current
technology available to promote software reuse.  That certainly includes
Ada.  Of course, it would be easy to fix Ada so that it is object-oriented,
and several groups have done so, but the result is no longer official Ada.

There is a certain company that has a great Ada programming environment.
Their customers often call up and ask how a certain feature was implemented
in the environment, since they have figured out that they need to do the
same thing in their application.  They are sheepishly told that the feature
is implemented using an extension to Ada, and consequently the compiler that
implements the extension is not true Ada and the company is not giving away
the compiler.  This extension essentially adds dynamically bound procedure
calls to Ada.