On 24-ago-10, at 04:26, dsimcha wrote:
[...]
3. Ranges are the flagship way of iterating through an object in D,
as they
should be. opApply has its uses, but they're relatively few and far
between. I'm
wondering if anyone besides bearophile and I think supporting
opApply is worth the
effort and potential bloat, if Walter cares enough to fix Bug 2443,
and if Andrei
considers it to be a reasonable part of std.range/std.algorithm's
design.
I already defended opApply in the past let me put this here again:
ranges abstract away one iteration step. This is useful because it
means that combining several of them, adancing in locksteo,... is
possible and easy to do
opApply abstracts away a whole loop. This makes complex loops simpler
to realize without having to resort to fibers, and it allows
*parallel* looping in a natural way (which cannot be done directly
using only single iteration operations.
In blip/dchem I use this quite a bit (for example for parallel loop
helpers, often my objects have obj.sLopp
obj.pLoop(blocksize=dafaultVal)).
I like very much to be able to do foreach (x;obj.pLoop){...}
Now they obviously are different kinds of abstractions, so looping in
lockstep is not possible with opApply, at most you can lockstep *one*
opApply with N iterators.
About the operations in algorithm well I am not too sure how much
support there should be, if they require just looping then yes, but
(for example) I think that almost all of them would fail if feeded
with a parallel opApply.
For sequential loops fibers can transform opApply in an iterator (just
as fibers can be used to easily make an iterator out of a complex loop).
But fiber have a relatively high cost.
So I suppose I would give support just to the basic stuff + conversion
for sequential loops (via fibers), keeping most of std.algorithm
opApply free
Fawzi
