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
