On Tue, Jun 11, 2013 at 11:22 AM, Jakob Ovrum <[email protected]> wrote:
> On Tuesday, 11 June 2013 at 13:13:56 UTC, Daniel Murphy wrote: > >> Also, compress is a ridiculously general name for a function. >> > > We have module-level functions called "copy" (multiple), "read", "write", > "map", etc. already, and it's not a bad thing! > > It's OK because the full name is not "compress", but "std.compression.lz77. > **compress". This way, how specific the code wants to be depends on the > user and the particular use-case, instead of one-size-fits-all alternatives > like "lz77Compress". There's no redundancy in the name yet we still have > the option to be pin-point specific (e.g. static import), and yes, we still > get to use UFCS! > > To eliminate the UFCS problem - which doesn't happen very often (how often > do you want to use two different compression algorithms in the same unit?), > we can (must?) use renamed symbols when importing. > I have found a better way to do that: see http://forum.dlang.org/post/[email protected] subject: 'best way to handle UFCS with ambiguous names: using std.typetuple.Alias!' syntax: 'arg1.Alias!(std.file.write).arg2'* see related discussion for reasoning. I'd like to push this as standard way to deal with ambiguities. > > Since any example using multiple "compress" functions would be contrived, > I'll use an existing conflict - the case of "copy". > > The following program backs up the specified files and writes a nicely > formatted message to stdout (OK, so a tiny bit contrived): > ---- > void main(string[] args) > { > import std.algorithm : chain, copy, joiner; > import std.array : empty; > import std.file : fileCopy = copy; // `fileCopy` is std.file.copy > import std.stdio : stdout; > > auto fileNames = args[1 .. $]; > > foreach(fileName; fileNames) > fileName.fileCopy(fileName ~ ".bak"); > > if(!fileNames.empty) > "Backed up the following files: " > .chain(fileNames.joiner(", ")) > .copy(stdout.**lockingTextWriter()); > } > ---- > > By eliminating redundancies from symbol names, we empower the user, and > the module system offers all the tools necessary to solve conflicts in a > variety of ways. >
