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 <[email protected]>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 :-) >
