Decision on container design

[Simon Buerger]

On 28.01.2011 19:31, Andrei Alexandrescu wrote:
> 1. Containers will be classes.
>
> 2. Most of the methods in existing containers will be final. It's up
> to the container to make a method final or not.
>
> 3. Containers and their ranges decide whether they give away
> references to their objects. Sealing is a great idea but it makes
> everybody's life too complicated. I'll defer sealing to future
> improvements in the language and/or the reflection subsystem.
>
> 4. Containers will assume that objects are cheap to copy so they won't
> worry about moving primitives.

Not perfectly what I would like, but a reasonable choice, and most 
important to actually have a mature container-lib. But there are other 
choices remaining: what containers will be there and what will they be 
called? My suggestion is

* Set, MulitSet, Map, MultiMap (hash-table based)
* OrderedSet, OrderedMultiSet, OrderedMap, OrderedMultiMap (tree-based)
* Sequence (like stl-Deque. the name is just more intuitive. Funny 
enough, the stl-deque implemenation has nothing to do with a "doubly 
linked list")
* Array (like stl-vector. I think "vector" is a kinda strange name, 
but that may be only my impression)
* List (linked list)

* Stack/Queue/PriorityQueue should be done on top of an other class, 
with a "impl"-template-param, like the stl-ones

Things to note:
* container should be named with respect to their use, not the 
implementation. "HashSet" is a bad name, because the user shouldnt 
care about the implemenation.

* unordered sets are used more often than ordered. So it should be 
"Set/OrderedSet", and not "UnorderedSet/Set" (also, the first one is 
two characters less typing *g*)

* opEqual should work between different types of Sets (or Maps, or 
sequences). Nothing wrong with comparing an ordered to an unordered 
one, or a list to an array.

just my 2 cents,
Krox