Container hierarchy vs. container types

[Jonathan M Davis]

I'd definitely go with the unconnected class solution. Sometimes it's useful 
to be able to have a class hierarchy where you don't have to care whether 
about things like whether a Map is a HashMap or a SortedMap, but it 
frequently comes back to bite you - especially when they require that 
different operations be implemented by the elements they hold. It can easily 
lead to an inefficient use of containers - especially after changing one 
type for another. Additionally, from a performance perspective, by avoiding 
the class hierarchy, it's possible for them to be final and allow inlining 
and such. So, there are performance gains by avoiding the class hiercharchy.

Also, I recall Scott Meyers talking in Effective STL how containers aren't 
truly interchangeable and how you can get yourself into trouble when you try 
and swap one out for another. You really should be aware of what container 
type your using and what it's strengths and weaknesses are.

What it generally comes down to is that you want containers to have the same 
functions when they do the same thing, so that it's possible to swap one for 
another when you want to. The same API is generally enough for that. The 
fact that D has auto makes it that much easier. Being able to swap out 
vector and list or ArrayList and LinkedList can be useful in some 
circumstances, but having a List which could be either (or yet another 
unknown type) is not all that useful, generally speaking. And, as I said 
before, it makes it really easy to use such containers in inefficient ways 
since the performance of each operation of each operation can differ 
significantly depending on the type. It also leads to using only the 
functions which are the lowest common denominator, which means that the 
containers are not used to their full potential and are probably being used 
less efficiently.

If you have a set of unconnected container classes and someone wants a 
hierarchy of containers for their project, it would be quite simple to set 
up a set of wrapper classes for the containers that they want to be in a 
hierarchy. On the other hand, you can't take a class hierarchy and use a 
wrapper class to turn it into a flat set of unconnected containers.

I say that it makes sense for functions with the same behavior to have the 
same names, so that you can effectively duck type the containers, but I 
don't see much benefit in putting them in a hierarchy where you supposedly 
don't have to care about what the actual container is that you're using as 
long as it implements a particular interface.

In any case, I'm glad to see that you're finally working on the container 
problem. I think that it's easily the thing that phobos lacks most, and it 
would definitely be easier to get people to use D, if there were containers. 
Most programmers I know would probably not touch D as long as there are no 
standard containers. It'll be good once we have them. And hopefully, they'll 
be awesome.

- Jonathan M Davis