Ranges

[Yigal Chripun]

bearophile wrote:
> 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.
> 

I thought about using an enum as well, but am unsure what's simpler in 
this case. I'm not in love with D's enum construct.

> 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.

what you talk about above is the tradeoff between client iteration (C++ 
iterators) vs. container iteration (functional each method). being a 
Python programmer you prefer the second but both have pros and cons.
you can always combine both (coroutines/fibers/etc..) but that has a 
performance cost.
all the above have their benefits and you should use what's appropriate 
for the task at hand, instead of religiously committing yourself to just 
one.
the benefit of client side iteration like with ranges is that client 
code gets fine grained control over the iteration process.

personally, I think opApply should be removed. it provides "push" style 
iteration which should be provided as a "each" method of the container.
the "pull" style of ranges should be used with client side looping.

> 
> -------------------------------
> 
> 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?

I mentioned arrays in my original post as an exception but I feel that 
in general it shouldn't be conflated in order to get a cleaner design.
where else would it make sense to you to conflate the two except arrays 
and maybe linked-lists?

I think this separation of concerns is a good thing.


> 
> Bye,
> bearophile