Decision on container design

[KennyTM~]

On Jan 30, 11 01:09, Simon Buerger 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")

A 'deque' just mean a double-ended queue, not necessarily doubly linked 
list. I don't like the name Sequence since it doesn't specify the 
container can be modified from both ends. 'Deque' is just fine.

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

Except that there is already a std.container.RedBlackTree named in this 
fashion :).

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

This breaks transitivity of '==' unnecessarily. I don't see the benefit 
of comparing two different kinds of containers. If you really need to 
compare them, use std.algorithm.equal.

> just my 2 cents,
> Krox