Initially, I did the same thing with the containers. In fact, I did the same thing with containers before I even did it with iterators. However, I now realize this was rather silly. There's a lot of duplication in the definitions of sequences and associative containers. For instance, the only Sequence methods that aren't also in Associative Containers are insert(p, n, t) and insert(p, i, j) [erase(q) and erase(q1, q2) are present in both, but have different return values ... I must admit I don't understand why].
Theoretically, this isn't that big a deal; you can just duplicate the definitions. This is exactly what I did initially. However, then generic algorithms can't work on both Sequences and Associative Containers except via iterators, even if they are restricted to the common interface. See, for instance, insert_iterator. In C++ that works with both types, but C# requires a common type that defines the insert(p, i) method.
So should that common type exist? If so, should it do all of the common methods?
What I'm leaning towards now is inserting a ModifiableContainer type between Container and Sequence/Associative Container. Right now, Container is pretty much read only, and I figure that's a pretty useful distinction to have. So adding a second layer with the inserts and erases makes sense to me. But then I wonder if the extra complexity is justified, and if I shouldn't just put it all into the base Container type. Or maybe even make it completely orthogonal...right now I have a BackInsertSequence type that defines PushBack, PopBack, and Back; why not have an InsertSequence type that defines Insert and Erase?
Bah, explicit type constraints are making this a lot harder than it needs to be [sad] It was so much nicer when I could let the C++ standards committee do my design for me. Now I'm going to have to sit down and draw out exactly what I want everything to be capable of, and what I don't want them to be capable of, and go from there. Uber boring.
CM
