Re: Bases 1.52

[amado.alves@netcabo.pt (Mário Amado Alves)]

(I'm sorry if my replies are so delayed. Currently I have no news
server except Google.)

Martin Krischik <krischik@users.sourceforge.net> wrote in message news:<1301057.xhkpTmYQhd@linux1.krischik.com>...
> M�rio Amado Alves wrote:
> 
> > Martin Krischik wrote:
> >> 51   This parameter shall have the signature
> >>        type Element (<>) is private;
> >> 
> >> Why restrict to just one signature?
> >> 
> >> I have made very good experiences with containers based on:
> >> 
> >>    type Item (<>) is abstract tagged private;
> >> 
> >> This frees my applications from using heap memory when I need to store
> >> Item'Class instances....
> > 
> > I'm not sure about the memory management implications, but doesn't the
> > first signature include the second, in the sense that it accepts
> > tagged actuals?
> 
> Yes, but to my knowlege you cant say:
> 
> type Item'Class is private;

I don't follow. Do you mean the formal in 1.51 does not accept a class
wide actual? But it does.

But you're right in that the formal in 1.51 does not accept abstract
actuals. However I'm not sure about the usefulness--or even
legality--of a container of abstract elements. Note the Bases requires
"value semantics". Abstract types don't have values.

>...
> > Restricting to just one signature is simply to keep the library small.
> 
> Shure, but one often likes to store Strings or a decendant of a tagged type.
> With Strings one can use Unbounded_Strings but with tagged type on is lost.

Sorry, I don't see the problem.

> Besides, Sun did not keep the Java Library small. In fact the Java Library
> is huge. And Java is more successfull.
> 
> Or Python. The Python Library is huge and there are 2641 python project on
> source forge and ony 67 Ada projects. 

Do you mean the *containers* library?

Anyway, I think I'm ok with reformulating requirement 1.51 to just
"the library shall support containers of indefinite elements." This
covers class wide, and leaves open the decision for abstracts. However
we should check in the body of knowledge (or right here and now) if
there is consensus.

As for the library size, the tendency is to recommend a maximum of 50
lines per package spec. And the Bases requires Vectors, Lists and
Tables (maps), but leaves open the inclusion of others.

BTW, Bases 2 has been submited to the ARG.