On Sat, 29 Jan 2011 12:09:00 -0500, Simon Buerger <k...@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
