std.compress

[Timothee Cour]

What I suggested in my original post didn't involve any
indirection/abstraction; simply a renaming to be consistent with existing
zlib (see my points A+B in my 1st post on this thread):

std.compress.zlib.compress
std.compress.zlib.uncompress
std.compress.lzw.compress
std.compress.lzw.uncompress

same reason we have: std.file.write, std.stdio.write, etc, and not
std.fileWrite, std.stdioWrite.

On Tue, Jun 4, 2013 at 11:18 PM, Walter Bright
<newshound2 at digitalmars.com>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.
>
> 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().
>
> 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.
>
> I am actually wrong in saying it has zero value. It has negative value :-)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130604/83ef0070/attachment.html>