On Wednesday, 5 June 2013 at 06:18:54 UTC, Walter Bright wrote:
On 6/4/2013 9:44 PM, Max Samukha wrote:
On Tuesday, 4 June 2013 at 18:46:49 UTC, Walter Bright wrote:
On 6/4/2013 11:43 AM, Timothee Cour wrote:
writing generic code.
same reason as why we prefer:
auto y=to!double(x) over auto y=to_double(x);
The situations aren't comparable. The to!double case is
parameterizing with a
type, the compress one is not. Secondly, compress(lzw) does
ABSOLUTELY NOTHING
but turn around and call lzw. It adds nothing.
That "absolutely" based on limited personal experience is the
biggest D's problem.
I've seen an awful lot of abstractions over the years that
provided zero value.
I understand. But I've also seen a lot of abstractions over the
years that seemed useless initially but were discovered to be
extremely useful later (Bayes theorem is an example - it took 300
years to find a concrete use for it). So "a compelling use case"
is not a sufficient criterion for evaluating usefulness of
abstractions.
You need to provide a compelling use case to justify another
layer of complexity. "generic code" is not a compelling use
case. It's already generic.
Note how these components are to be used:
src.lzwCompress.copy(dst);
Your proposal is:
src.compress(lzw).copy(dst);
I.e. zero value, as so far all compress() does is call lzw().
That's not my proposal. Honestly I didn't even take a close look
at it. I just felt like it was time to attack you - there is an
explicit permission for casual trolling you gave.
The whole point of range-based pipeline programming is you can
just plug in different components. There is no demonstrated use
case for adding another layer.
Ok.
I am actually wrong in saying it has zero value. It has
negative value :-)
In this particular case, maybe.
