Andrei Alexandrescu wrote:
I decided to let no assumption unchallenged and got back to the question: do we really need a container _hierarchy_? How much joy and usefulness do people derive from dynamically changing an array with a list under the same interface? Or a rb-tree vs. a binary tree vs. a left-leaning binary tree?
I've never, in 35 years of programming, ever had a need to change the container type at runtime. I don't think the thought has ever even crossed my mind. I appreciate bearophile's point of runtime profiling being used to change the container, but I suggest that such containers be internally self-modifying, rather than externally using user-visible virtual functions.
I more and more like the idea of having a set of names defined by convention that have conventional behaviors, in other words, duck typing. It's infinitely extendable and flexible without needing to modify the core library in any way. It also fits right in with D's template constraints.
The bit flag approach is not pretty. Furthermore, to add a capability means one has to redo that enum in the core library, which is not scalable and people don't like making their own custom core libraries. Even if they did, it makes for mutually incompatible third party libraries. Yuk.
