Yigal Chripun wrote:
BLS wrote:
dsimcha wrote:
Ranges are just pretty much an implicit compile-time interface. As
Ary put it,
compile time duck typing is a pretty accurate description.
Basically, a range
doesn't have to *be* a specific *type*, it just has to support
certain specific
*operations*, namely front, popFront, and empty. As long as it *has*
these
operations, and they compile and return what they're supposed to
(ElementType!(T)
for front(), void for popFront() and bool for empty), it doesn't
matter what type
it *is*.
What I don't get is how this (definition) may work on tree based
structures. To me it seems that ranges work fine on "linear" data
types (whatever) lists, but well, as said I don't get it. :(
as I understand this, A range is alway some linear (iteration) order of
the elements.
so a tree structure can provide:
tree.preOrder()
tree.inOrder()
tree.postOrder()
which return three different ranges representing these orderings of the
tree elements.
a sub-tree will be of type tree itself and has nothing to do with ranges.
you can of course combine the two, e.g.:
AVLtree.left.right.left.postOrder;
for linear structures. e.g. an array these two operations are the same.
int[100] arr;
auto slice = arr[40, 50];
slice is both a sub-array and a range of that sub-array.
Thanks, Yes that makes sense.
