Re: 2 Ada 95/05 language design questions

[pnkflyd831@gmail.com]

On Feb 15, 3:35 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> pnkflyd...@gmail.com writes:
> > I find Ada to be an excellent embedded, real-time, OO language.
> > However I've noticed over the course of my 3 years programming with
> > the language 2 ways in which the language behaves that I question the
> > designers on their rationale.
>
> Interesting ideas.
>
> > The first question deals with the decision not to allow the
> > declaration of abstract subprograms within the private part of a
> > package (that contains a public abstract tagged type, and uses it as
> > the controlling operand).  See Ada 05 LRM section 3.9.3(10).  The
> > Annotated LRM gives a rational (derived tagged types not declared in
> > child packages would not have visibility to these abstract
> > subprograms), but wouldn't the better option to be to force derived
> > tagged type to be declared in the same or child packages than to have
> > to make public the abstract subprogram?  I do not like the idea of
> > allowing external objects access to methods that could potentially
> > leave the aforementioned class objects in an inconsistant state.
> > (Attempts to impliment the Template Method design pattern suffer from
> > this issue)
>
> That's a legitimate complaint.  However, I think you're suggested cure
> is worse than the disease.  You're saying that all (tagged?) type
> derivations must happen within the same hierarchy of child packages,
> right?  That seems like an onerous restriction, to me.  Quite often, you
> want clients, with no visibility on the private part, to derive from the
> type and override some operations.
>
> Consider some of the predefined types.  I don't think you want all
> controlled types to be declared in children of Ada.Finalization,
> nor all types derived from Root_Stream_Type to be declared in children
> of Ada.Streams!
>
> One solution would be to have some syntax that means "this type might
> have some private abstract operations, and therefore all derivations
> from it must be in places where the full type is visible".  But I don't
> think you want to treat ALL types that way.
>

Your absolutely correct.  My intent was not that all derived type
linages must match the package lineage.  Additional syntax or the fact
that the private abstract subprogram is still visible from the spec to
the compiler and it could complain at compile time when you attempt to
create a child that doesn't have the full type visible.

>
> Again, a legitimate complaint.  In fact, various people complained about
> this over the past decade, and the response was to add the dot-notation
> call syntax in Ada 2005.  You say that makes the "impact less severe".
> Would you agree with "eliminates the problem"?

You still have to with in the parent tagged types package.  When
refactoring this can still be annoying, but other languages have worse
problems so it's definitely no deal breaker.