Re: Choice of OO primitives in Ada95

[milod@netcom.com (John DiCamillo)]

ncohen@watson.ibm.com (Norman H. Cohen) writes:
>|> Tucker Taft wrote: 
>|> : ...  The orthogonality of
>|> : types and modules in Ada 95 can be a major advantage,
>|> : gives the programmer more flexibility in structuring their system

But Cardelli and Wegner [CW85] showed that the opposite is
true: providing package types through existential quantification
is *more* flexible than having typeless package values as
Ada provides.  It also simplifies and unifies the concept of Ada
generic packages, which are almost package types, and allows
package values to be treated as first-class values.

To be sure, C&W based their analysis on a type system supporting
first class functional values (not present in Ada), so their
conclusions may not hold for Ada.  However, I find it difficult
to believe that the converse is actually true.

>|> What flexibility does this approach offer over conventionally encapsulated classes?

>1. It allows other forms of encapsulation and packaging, not involving
>   classes.  We could have a package providing a nonextendible private
>   type for complex numbers, deferred constants zero, one, and i, and a
>   set of arithmetic operations.  We could have a package providing a set
>   of constants.  We could have a package providing a set of
>   higher-level auxiliary routines operating on a type provided by
>   another package, building on the primitive operations provided by that
>   package.  I've seen people try to use C++ classes with no nonstatic
>   members for these other forms of encapsulation and packaging, and the
>   result is strained.

"Strained" in what way?  _D&E_ [Stroustrup94] mentions several
minor problems with this approach, but seems to be considering
using classes to wrap already existing global declarations.
(btw, i'm not disagreeing, just asking for clarification)

>   That's one reason C++ has added namespaces, which
>   are like Ada packages.

Sort of... Namespaces simply control name visibility, they are
not an abstraction mechanism.  Namespaces do not have private
parts.  Namespaces may be extended by multiple declarations.

>   But once the full generality of Ada-like
>   packages is available, the class program unit as an encapsulation
>   mechanism is redundant.

Again, sort of.  Why talk of adding a separate class program unit?
Why not just extend packages to provide package types?  That way,
you have only one mechanism for encapsulation (the package) and
packages become first class values, allowing for more flexible
package declarations and increased code-reuse.

[big snip]

>Ada certainly recognizes a close relationship among packages, types, and
>operations:  If a package provides both a type and subprograms with
>parameters or results of that type, those subprograms "belong" to the
>type.  (In the technical jargon, they are "primitive operations" of the
>type.)

>But a package is a module, not a type.

Which is the whole problem, despite what the rationale tries to
claim, IMHO.  Ada, despite being a very type-centric programming
language, has too limited a concept of types.

>The unnatural modeling of
>one-per-class data items as static "members" in C++ comes from an attempt
>to force-fit the two concepts into a single construct.

Not at all.  The unnatural modeling comes from a lack of class
values in C++.  This same problem causes the awkward semantics
of constructors and destructors.  In other words, static members
are a C++ problem, not a class problem.

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

-- 
    ciao,
    milo
================================================================
    John DiCamillo                         Fiery the Angels Fell 
    milod@netcom.com       Deep thunder rode around their shores