Decision on container design

[Steven Schveighoffer]

On Sat, 29 Jan 2011 12:09:00 -0500, Simon Buerger <krox at gmx.net> wrote:

> 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.

http://www.dsource.org/projects/dcollections

-Steve