dsimcha wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
dsimcha wrote:
One point of clarification: opApply isn't going to be deprecated anytime soon,
is
it? It seems like ranges still have a bunch of rough edges, and although I like
the idea in principle, I'm only willing to convert to ranges if I can define
iterable objects with the same level of syntactic sugar as opApply gives me.
For
simple cases this is already true and I have begun converting some stuff.
However, for more complicated cases, opApply is still a lot more flexible.
opApply isn't going away. For one thing, it works very well with
recursive data structures.
So besides performance, what advantages does using ranges instead of opApply for
iteration over structs/classes offer? According to some testing that I just
finished on the hash table implementation I was talking about earlier today, the
penalty for using opApply is small enough that, if using ranges requires a bunch
of extra bookkeeping overhead that opApply doesn't, then opApply can reasonably
be
faster.
Speed is a small part of the equation, in fact a perk only. Ranges are
composable; you can combine them to e.g. do parallel iteration over two
ranges. Ranges really open std.algorithm to all data structures. I find
opApply incredibly obtuse and fostering bad design. I wish it goes away.
Andrei
