On Wed, 22 Jun 2011 09:17:56 +0300, Andrej Mitrovic
<andrej.mitrov...@gmail.com> wrote:
Another example is std.parallelism.taskPool. It's nice to see code like
this:
taskPool.reduce!"a + b * b"(0.0, nums);
I'll never mistake that for std.algorithm.reduce. And it's not too hard
to type.
I am confused, you said typing module names tedious and now you are saying
it is fine typing taskPool.reduce every time.
If adding "taskPool" at the beginning is not a problem then so is adding
"algorithm". How about this improvement?
If we are able to refer std.module.foo as foo, why can't we refer it as
module.foo? The reason probably is the confusion arises when
"fun.mod.impl" and "mod.impl" exists at the same time
Someone mentioned that we shouldn't use structs as name wrappers
because that's against "D's philosophy" and it's working around the D
module system. Well, the D module system might do a great job at
protecting function hijacking, but wasting programmer time on name
clashes could be as frustrating as hunting down a function hijack in
some /lesser/ module system.
That's my 2 cents..
I don't know who said but i agree it is wrong, not using the hack, but the
need of a hack with the existence of a language feature for that purpose.
If we need a hack, we are in need of improving the feature.
