Re: Ada Generic Library (very) preliminary release

[Brian Rogoff <bpr@shellx.best.com>]

On Sun, 13 Jul 1997, Matthew Heaney wrote:
> In article <Pine.SGI.3.95.970709082112.10832B-100000@shellx.best.com>,
> Brian Rogoff <bpr@shellx.best.com> wrote:
> >Deliberate choice. STL uses no dynamic dispatch, and strives for the
> >efficiency of "hand coded C". While it may not be there, automatic
> >finalization of components won't help the Ada version. 
> 
> There may be confusion here: in Ada 95, there is no dynamic dispatch unless
> it's on a class-wide object.  There is only a small space-penalty, to store
> the tag.

I am aware of the "dispatch at call site" nature of Ada 95 OO. But the 
STL is an emphatically non-OO library, and I have decided to explore 
that design space, rather than using an OO approach.  

> Be very careful about using the STL - written in C++, using all the idioms
> of that language - as a model for an Ada 95 component library.

Based on a library developed in Ada 83, based on one in Scheme, ...

No, that argument doesn't work. What I like about STL is not C++ specific, 
and though there are some things about C++ that make the expression of
this library cleaner (gasp!), for example the ability to interleave public
and private parts of a class, there are lots of things that allow the 
Ada version to be cleaner.

STL is based on an analysis of the underlying structure of many algorithms, 
and is more rooted in algebraic specification than in BS-oriented, er, 
object-oriented programming. :-) It pretty much pushes the "cursor" type 
iterator design as far as possible. Yes, there are higher level ways to 
do iteration (Sather style iters, Icon style goal directed evaluation, ...)
but the STL approach makes sense for an Ada 95 collection component
library.

STL is not just a collection of language dependent idioms. If you want to 
argue against it, you should at least have an understanding of it!

> It would be true, however, that if Root_Stack derived (either publicly or
> privately) from Finalization.Controlled, then there would be a small
> penalty to call Initialize, Finalize, and Adjust, a penalty that need not
> be incured by bounded forms (ie, implemented as an array).

How small is this "small penalty"? I guess what you and I should do is 
measure the overhead of the suggested approaches, if efficiency were the 
overriding concern (it isn't, but I'm still intrereseted). 

> To get maximum efficiency (and to not give those programmers with
> "optimitis" the excuse not to use the library), the library designer might
> very well decide to not inherit from controlled at the root, and to
> implement an unbounded form (say) by extending the uncontrolled parent with
> a component that is controlled.  This localizes the "inefficiency" of
> controlled type usage to only those branches where it is strictly required.

This is what I am suggesting for all of the AGL components. If you want
safe versions "roll your own" from AGL. I'll probably provide safe versions 
"pre-wrapped", but it isn't a high priority with me now. (The high priority 
is finding a better way around the interleaving omission I mention above, 
since it forces too much to be public, as Mats Weber pointed out. I know 
this, but I am uncertain as to what to do. One solution might be to just
break up the iterator child package into two or more, and use with clauses
to "order" the elaboration of the children). 

-- Brian