Class/Interface Modeling of Ranges

dsimcha dsimcha at yahoo.com
Fri Nov 20 18:17:24 PST 2009


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.



More information about the Digitalmars-d mailing list