Ranges

[bearophile]

Yigal Chripun:

> so a tree structure can provide:
> tree.preOrder()
> tree.inOrder()
> tree.postOrder()
> which return three different ranges representing these orderings of the 
> tree elements.

This is right, and in some situations it may even be possible to provide a generic scan:
tree.scan(ScanType.PREORDER)
tree.scan(ScanType.LIMITEDDEPHT)
etc.

But from my first experiments with the range protocol I have seen that the "pushing" style of opApply (and the syntactically nicer yield in Python and C#) sometimes leads to simpler to write iteration code.
For example defining a opApply that scans a tree by pre-order is very easy, you just put the yield (or the equivalent machinery of opApply) where you want to process a leaf of the tree. But when you use the range protocol you have to split that code in parts and you must manage the state yourself manually. This can sometimes be tricky and maybe even bug-prone.

-------------------------------

Kristian Kilpi:

>Hmm, should the Range methods use some special naming convention? E.g. rangeFront(), rangePopFront()...?<

Time ago I have suggested something like opFront, opEmpty, etc, like the normal D operators.

-------------------------------

Yigal Chripun:

>while I agree with the general point about the naming convention, I don't see how is this a problem here since a range should be a distinct type from the container.<

Is this always true? In a simple data structure I may want to conflate the iteration protocol with the data structure itself, for example for an array type. Is this a bad/wrong design?

Bye,
bearophile