comp.lang.ada
 help / color / mirror / Atom feed
From: pnkflyd831@gmail.com
Subject: 2 Ada 95/05 language design questions
Date: 15 Feb 2007 08:21:48 -0800
Date: 2007-02-15T08:21:48-08:00	[thread overview]
Message-ID: <1171556508.585271.80780@v45g2000cwv.googlegroups.com> (raw)

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.

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)


The second question deals with the decision not to have derived tagged
types inherit the "primitive" classwide subprograms of their publicly
declared parents.  See Ada 05 LRM section 3.4(16,17/2, & 23/2) which
states that only primitive operations are inherited and made visible.
In Ada 95 it seems silly to have to with in the package where the
classwide subprogram is declared to use it, and then the package
reference has to be repeated every time the classwide subprogram is
called unless a use clause is present.  The calling object should not
have to distinguish between dispatching and classwide operations when
they have a child derived type view of the object.   In Ada 05, the
impact is less severe because of the dot notation,  but I am still
curious as to why the decision was made. (Code which works with the
child derived type object instead of the parent view of the object
suffer from this issue).




             reply	other threads:[~2007-02-15 16:21 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-15 16:21 pnkflyd831 [this message]
2007-02-15 18:33 ` 2 Ada 95/05 language design questions Adam Beneschan
2007-02-15 18:36 ` Dmitry A. Kazakov
2007-02-15 20:35 ` Robert A Duff
2007-02-15 22:59   ` pnkflyd831
2007-02-16  1:51     ` Randy Brukardt
2007-02-16 18:52     ` Adam Beneschan
2007-02-15 21:51 ` Simon Wright
2007-02-15 23:00 ` pnkflyd831
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox