Re: How come Ada isn't more popular?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Fri, 9 Feb 2007 22:18:51 -0600, Randy Brukardt wrote:

> Dmitry A. Kazakov writes:
> ...
>> Because it does not compose upon inheritance and aggregation.
>>
>> When inherited the constructing function need to be overridden, even if
>> null record was the only thing added.
> 
> That's not true in Ada 2007. (That's a change I strongly opposed, BTW,
> because it makes prototyping much harder. I usually start an extension with
> a null record, figure out what needs to be overridden (giving those null
> bodies), and then implement the actual routines and data. This no longer
> works, because as soon as you add an extension component you are back to
> square one.)

Yuck. Do I understand correctly, primitive operations are no more covariant
in the result?

   type T is tagged ...;
   function Foo return T;

   type S is new T ...;
      -- I don't need to override Foo????

>> Further one can barely publicly
>> derive anything from T, which breaks encapsulation.
> 
> Not sure what you mean by this. It's certainly possible for a deivation to
> break encapsulation (by deriving in a child unit, for instance),

Which is not always desirable or even possible, as we don't have multiple
parents (alas!).

> It is annoying that we couldn't find a way to get composition to work for
> anything other than :=, =, and stream attributes.

I think that the problem is that we have no unified composition model for
primitive operations. Things composed per magic (like ":=" or dispatching
subprograms) use different rules. Why don't we try to expose this mechanics
in the language? There certainly exist a common denominator of how
operations are composed. It is either of:

    g := f o g  -- f extends g
    g := g o f  -- f prepends g
    g := f       -- f replaces g
    g := e o g o p -- prologue and epilogue (conversion)
                   -- (like in out Natural accepting actual Integer)

All primitive operations including assignment, attributes, constructors
(from raw memory to object's invariant), destructors (backwards),
aggregates, conversions fall under some combination of these patterns.

This could radically simplify the language (fully backward compatible of
course).

> (The lack of it for
> finalization routines is especially aggrevating and error prone.)

Yes, especially, because there is no name for parent's Initialize/Finalize.

> But the
> workarounds for constructors aren't particularly bad, especially as you can
> use extension aggregates in your overridings.
> 
>       (F with <new components>);

Yes, aggregates compose (which is good), but they aren't functions. There
is an underlying thing which IMO should be named and exposed.

BTW, the aggregate above is almost equivalent to C++'s constructor
definition

    Derived::Derived (...) : F(...), <new components> {}

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de