I'm thinking about what the best way might be to model ranges in an OO/inheritance style for collections/containers, and needless to say it's pretty complicated and virtually impossible to model well. (As an aside, this is why I like duck typing, be it compile time or traditional, so much.)
At the top of the hierarchy is forward ranges, or maybe input ranges. Bidirectional ranges are obviously a subclass of input ranges. Then things get ugly. 1. Random access ranges must also be bidirectional and define back() and popBack() iff the range is finite. Does iRandomAccessRange(T) inherit from iForwardRange(T), iBidirectionalRange(T), or neither? 2. How about length and assignable elements? How do we fit these into the hierarchy? We get combinatorial explosion. We can't have an iRandomAccessRangeWithLengthAndAssignableElements(T), an iRandomAccessRange(T), an iRandomAccessRangeWithAssignableElements(T), ad nauseum. 3. Can we simplify this by using runtime exceptions instead of compile time errors for some of this stuff? For example, every range would have a hasLength() method and a length() method. If hasLength() is false, length() would throw. Though this sacrifices compile time error checking, it might be better in some ways. For example, if a given compile time type may or may not have length depending on its runtime type, you could check at runtime whether it has a length and adapt your handling of it accordingly.
