Re: List container strawman

[Ted Dennison<dennison@telepath.com>]

In article <mailman.1004730907.14961.comp.lang.ada@ada.eu.org>, Mike Brenner
says...
>
>Comment 3. There is no method of putting in a garbage collector.

*That's* the other thing I forgot! I was thinking of having a storage pool be an
optional parameter (the default being the default storage pool). Any problems
with that?

>Comment 4. The ability to delete, insert, move, swap, and copy things around might be useful. These would be fast in a double linked list and slow in a single linked list.

Delete and insert are now in there. The others aren't but could be accomplished
with delete and insert. Does anyone think they need their own routines anyway?

>
>Comment 5. I like Marin David Condic's idea of adding a load/store to put the 
>list to streams and 'read and 'write. Adding to that, I prefer all types to 

Done.

>have a string representation, for example:
>
>	function image(list: lists) return string;

In my own code, I'd agree. For something meant to fit nicely into the existing
Ada library, I'm not so sure. Remember that it wouldn't be too tough to do this
yourself using one of the iterators.

>Comment 7. I also agree that SORT should be a child package so we can 
>substitute a faster sort for whatever is provided. Also all higher 
>functionality should be substitutable through child packages, generic >parameters, or some other method.

You can *still* do that (or some important information in the declaration may be
deferred to the body, in which case you can't do either). All this does is
provide a default algorithm which is easy to use. However, it really doesn't
matter much at all syntacticly. This way just saves a "with".

>Comment 8. On copying the list, there is a convention in Python that there is a copy that just copies the top level of pointers and a deep_copy that copies all levels of pointers. Perhaps something like that could be invented here.

I don't think that would be feasible, since that would require client help for
any pointers that are in the Element type (its opaque to the List package). I'm
guessing Python doesn't have that issue?

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.