dsimcha wrote:
== Quote from Yigal Chripun ([email protected])'s article
dsimcha wrote:
== Quote from Yigal Chripun ([email protected])'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?
