std.path review: second update

[Jonathan M Davis]

> On Sun, 31 Jul 2011 12:21:46 -0700, Jonathan M Davis wrote:
> > On Sunday 31 July 2011 14:24:30 Lars T. Kyllingstad wrote:
> >> On Fri, 29 Jul 2011 18:06:58 +0000, Lars T. Kyllingstad wrote:
> >> > Here's a new update based on your comments and requests. [...]
> >> 
> >> You may have noticed that I did not incorporate Steve's suggestion to
> >> make the directory separator(s) a template parameter. The reason is
> >> that this is the *smallest* difference between paths on the different
> >> platforms. Drive letters and UNC paths are a much bigger difference,
> >> and make interoperability near impossible.
> >> 
> >> Therefore, I would just like to reiterate a suggestion I made on the
> >> Phobos list a while ago, which was then shot down. What if we put the
> >> 
> >> entire module inside a template, like this:
> >> enum Platform { windows, posix }
> >> enum CaseSensitive { yes, no }
> >> 
> >> template Path(Platform platform, CaseSensitive caseSensitive) {
> >> 
> >> /* Every function in the module goes inside this template,
> >> 
> >> and instead of
> >> 
> >> version (Windows) { ... }
> >> 
> >> and so on, we use
> >> 
> >> static if (platform == Platform.windows) { ... }
> >> 
> >> That way, if people for some reason need to deal with POSIX
> >> paths on Windows, for instance, they can just write
> >> 
> >> Path!(Platform.posix).someFunction(myPath);
> >> 
> >> */
> >> 
> >> }
> >> 
> >> // Of course, we don't want to add a cumbersome prefix every time
> >> // we call a function for the current platform. By mixing in the
> >> // template, std.path can be used *exactly* like now:
> >> 
> >> version (Windows) private enum currentPlatform =
> >> Platform.windows; else version (Posix) private enum currentPlatform
> >> = Platform.posix;
> >> 
> >> mixin Path!(currentPlatform, platformDefaultCaseSensitivity);
> >> 
> >> What do you think?
> > 
> > Honestly, it seems like overkill and overly messy. Doing something that
> > drastic would have to add a lot of value IMHO, and I just don't see it.
> > And honestly, even if it _did_ add a lot of value, I think that I'd want
> > a cleaner solution to be found.
> 
> I don't see what's so messy or drastic about it. For the most part,
> you'd use the module *exactly* as you do now.
> 
> Handling paths from different platforms are not an uncommon need; people
> have requested more than once that this be possible with the new
> std.path. Zip archives and FTP clients/servers are good examples of use
> cases.
> 
> What's nice is that this doesn't have to be added now. We can make the
> change I suggest at any later time without breaking backwards
> compatibility.

It seems very messy to me from an implementation stand point. There's also the 
question about what it does to the spellchecker. If you type extensio instead 
of extension, will the spellchecker find it, or does the additional template 
obscure it? Also, can ddoc handle it? I'm not sure that a template mixin like 
that would be properly documented.

Maybe it's ultimately a good idea, but it seems to me like it stands a good 
chance of causing problems. We'd have to have a clear grasp of all of the side 
effects first.

- Jonathan M Davis