Re: An Ada9X mimic of C++ friends?

[ncohen@watson.ibm.com (Norman H. Cohen)]

In article <3hcao9$96b@solar.sky.net>, jhoward@solar.sky.net (John Howard)
writes: 

|> I come from a background with Borland Pascal dialects and recently I was
|> investigating Extended Pascal (ISO 10206:1991) and the latest
|> "Object-Oriented Extensions to Pascal" (ANS TR13 or X3J9/93-033).  With
|> Borland Pascal and C++ it was required to indicate in the definition of a
|> method whether it could be overridden (e.g. virtual) in a descendant class.
|>
|> Extended Pascal takes the opposite approach.  According to Appendix D.12
|> in X3J9/93-033 "Any visible method can be overridden in a descendant class.
|> A requirement to specify that a method can be overridden thwarts
|> specialization and code refinement.  It also requires an omniscient
|> designer who anticipates future use; or, it requires the user must have
|> access to the underlying code so that it can be changed.  Both of these
|> are poor assumptions."
|>
|> I am new to Ada.
|> So my question is: does the explicit use of "TAGGED" in Ada95 have the same
|> negative consequences as specifying "virtual"?

Note that "tagged" is specified per type, not per subprogram.  If a type
T is declared tagged, then any subprograms you declare in the same
package with parameters or results of type T will be dispatching
(virtual).  It is also perfectly reasonable in Ada 95 for subprograms in
that package to have parameters of type T'Class rather than T, in which
case they are not dispatching.  This is appropriate if the specifications
of the subprogram can be fulfilled using only properties common to all
types in the class.  These properties include the components declared at
the root of the class and other, possibly dispatching, subprograms
defined for all types in the class.  One need not be "omniscient" to
write a classwide subprogram that will work correctly for all present and
future subclasses.

(Example: Consider an abstract tagged type for mappings from integers to
integers, with a dispatching function Value_At that takes a mapping and
an integer and returns the value of that mapping at that integer.  There
may be several concrete extensions implementing mappings as arrays of
mapping values indexed by argument values, as linear lists of
argument-value pairs, and as hash tables, for example, each with a
different implementation of Value_At.  A classwide function
Value_Of_Composition_At, taking two mappings and an integer and returning
the value of the composition of the two mappings at that integer, can be
written as follows: 

   function Value_Of_Composition_At
      (Second, First: Mapping_Type'Class; Argument: Integer)
      return Integer is
      Intermediate_Result: Integer;
   begin
      Intermediate_Result := Value_At (First, Integer);
      return Value_At (Second, Intermediate_Result);
   end Value_Of_Composition_At;

Because of the two dispatching calls on Value_At--each of which may
dispatch to a different version--Value_Of_Composition_At will continue to
work for all kinds of mappings, even as new extensions of Mapping_Type
with their own Value_At functions are added to the system.)

I am not familiar with the OO extensions to Pascal, but I assume that
only entities declared as classes have overridable operations.  I presume
it is still possible to declare scalar types, record types, and array
types acted upon by subprograms that are not overridable.  The situation
is the same in Ada.  Declaring a type to be tagged is analogous to
declaring an OO Pascal type to be a class rather than an ordinary record
type.

It would, of course, be a major efficiency hit to require that all types
be extendable and all operations be overridable.  (Imagine viewing each
char in a string as an object, with its own dispatching-table pointer!)
The X3J9/93-033 language about "thwarting specialization and code
refinement" seems to presume that all programmers embrace the OO
paradigm.  Not all programmers do.  Ada 95 makes it easy, but not
mandatory, to do things in an OO style.  Programmers who choose to forego
the flexibility and maintainability promised by OOP advocates in return
for efficiency can do so by eschewing tagged types.  They can still
benefit from the use of a package as a module.

Of course it's not a black-and-white issue.  A reasonably designed
program may contain a mixture of OOP and non-OOP approaches.

--
Norman H. Cohen    ncohen@watson.ibm.com