On 3/24/2011 1:34 PM, spir wrote:
On 03/24/2011 05:32 PM, bearophile wrote:
I tried to keep it as consistent as possible with std.algorithm.
OK. Then the question is why std.algorithm uses normal strings instead
of q{} ones.
And regarding consistency with std.algorithm, a more important factor
is that std.algorithm.map is lazy, while you have a eager map, and the
lazy version has lazy in the name, so the names are kind of opposite
of std.algorithm.
I agree there should be a consistent naming scheme here. Aligning with
std.algo to consider lazy as standard sounds good. (Better than the
opposite anyway, maybe not as good as explicite for both cases --but
this is a lost fight ;-)
Denis
Thanks for the suggestions, everyone. I've made all the changes
suggested today, plus a few others:
1. map -> amap (eager), lazyMap -> map (lazy)
2. isPure is no longer documented, since it was never meant to be part
of the public API.
3. I put TaskPool.join() in a version(none) statement and removed all
references to it from the documentation. If anyone has a compelling
reason why this is useful (preferably with a good, short example), I'll
add it back. Otherwise, it's gone, since IMHO it's an evolutionary
artifact that makes sense in theory but that I can't think of a use for
anymore in practice.
4. After some prodding and thinking I've finally been convinced that
task() should just return auto. I thought documenting the return types
explicitly would clarify things, but from the questions I've gotten
about it, it seems to obfuscate more than it clarifies.
5. This one should have been done a long time ago: amap() now accepts
explicit buffers with element types that are implicit conversion targets
of the return type of the map function.
