Ranges

[Yigal Chripun]

dsimcha wrote:
> == Quote from Yigal Chripun (yigal100 at gmail.com)'s article
>> dsimcha wrote:
>>> == Quote from Yigal Chripun (yigal100 at gmail.com)'s article
>>>> 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.
>>> But the beauty of a lot of this stuff is that the syntax of iteration stays the
>>> same no matter how it works under the hood (builtins, ranges, opApply).  This is
>>> important for both generic programming and programmer convenience.
>> I'm not sure I follow this.
>> if you just want to do something with all elements than you're right but
>> if you want to do something more complex where you need to use the range
>> interface yourself than you can't use the foreach loop.
> 
> Yes, but a large portion of the time, iterating over all elements is all you need.
>  For example, if I want to write a generic function to find the mean and standard
> deviation of some object, I just need to be able to loop over it once.  I don't
> care if it uses a range, builtin arrays, builtin associative arrays, opApply, or
> pixie dust and magic.  The way this is done should be dead simple and consistent
> regardless of how it works under the hood.  Of course if you need to do something
> more complicated you may need to care about the details, but it's very often the
> case that you don't.

OK, that does makes sense. i thought that ranged are for those 
complicated situations but at a second thought there is no reason to 
have this limit.
the one consist way to iterate over the elements regardless of what's 
under the hood is the foreach loop so my question than is what is/should 
be the priorities between the different iteration modes?
if I have a container that provides both a range and opApply, which 
would be used by the compiler in the foreach loop?