Re: tagged types extensions - language design question

[Tucker Taft <stt@averstar.com>]

Vladimir Olensky wrote:
> 
> The question is :
> 
>    Why in Ada it is  not allowed to extend both public
>  and private part of the tagged type at one step ( using
>  kind of syntax as in the following example ):
> ...
> 
>     It would be interesting to know what were
> the reasons not to allow to have BOTH a record
> extension AND a private extension at the same time.

When designing a language there are hundreds of tradeoffs.
We chose a "building block" approach to Ada 95.  Rather than
trying to anticipate all uses, and make every feature have several
bells and whistles, we tried to provide features that can be
combined in an infinite number of ways to solve whatever problems
are encountered.

In general, if you start comparing languages, you are working in
the "solution" space rather than the "problem" space, and you will
generally be frustrated if you try to find an exact match in the
solution space.  The more important issue is whether you can solve
the problems of interest efficiently and effectively using the
features of the language you are evaluating.  

Personally, I would be more interested in real-world examples
of problems that in some sense require an abstraction whose
implementation is partly private and partly visible.  

In some of the problems I have seen, a natural solution 
in Ada is to implement the abstraction with a fully public 
record type, but make certain components of the
record be of a private type.  More often, I have found it better to implement
the abstraction using a fully private type, and then add set/get operations
as needed to expose certain components where appropriate.  Quite often
I end up discovering that either the "set" or "get" ends up requiring
more than a simple assignment or load from the corresponding component
of the underlying record, and I congratulate myself for having the "foresight"
(yeah, right) to use a fully-private type in the first place.

I suppose the ultimate answer is that the need for a partly private/
partly visible abstraction was thought to be rare enough that it
was felt to be better to keep the set of language primitives simpler, and
allow the programmer to combine them as needed to handle the more
complicated problems.  As usual, your mileage may vary... 

> Regards,
> Vladimir Olensky

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA