Re: list strawman

[dennison@telepath.com (Ted Dennison)]

Thomas Wolf <t_wolf@angelfire.com> wrote in message news:<MPG.16a629ebab6a7b63989682@news.ip-plus.net>...
> Some comments on that Strawman 1.4 interface:
> 2. Element Arrays
> -----------------
> 
>       type Element_Array is array (Natural range <>) of Element;
>       
> Why "Natural range <>"? I'd prefer "Positive range <>" similar to the

This has already been discussed, and it has in fact been changed to
positive. That's one of a couple of changes made since the last
strawman rev.

> 4. Removing from a list end
> ---------------------------
> You don't always want to get the old element when you remove an item
> from the list. Hence I'd add the following:
> 
>       procedure Remove
>         (Target   : in out List;
>          List_End : in     Direction);

We are past the point where we can add routines on a whim. People are
actually implementing it and writing code to work with it now. If a
routine is going to be added or changed at this point, it will be only
be for a very good reason (eg: A bug, or a very serious implementation
or usability problem).

> Two things: first, 'Quit' must be an "in out"-parameter, and second,

That's another thing that has already been discussed and changed.

> 7. Modifying an element at a given location
> -------------------------------------------
> 
>       procedure Modify (Subject   : in out List; 
>                         Location  : in     Iterator;
>                         New_Value : in     Element);
> 
> Why is the subject list passed along? To be consistent with the
> other operations on locations, it should be omitted.

Good catch there. I think I may have actually implemented this and not
noticed. Consider "Subject" removed.

> 9. Equality
> -----------
> Is there any harm done by putting them explicitly in the public part?

One does not put things in the public part of a package that do not
need to go there. So the proper question for putting things in the
public part of a package is not "Does it do any harm there?", but
rather, "Does it absolutely have to go there?" Again, I think the
proper model here is package Standard, which put a commented-out
version in the public part.

> 10. Stream Attributes
> ---------------------
> There's no need at all to make 'Stream_Read' and 'Stream_Write' public.
> I'd put them into the private part.

Again, this has already been discussed and done.

For the rest of your points, I have not addressed them because they
have already been debated and a decision has already been reached over
the last 3 months or so. Rather than have us rehash everything that
has been said before just for your benifit, I suggest you go review
the discussions and the rationale for the decisions at Google groups.