std.path review: second update

[Lars T. Kyllingstad]

On Mon, 01 Aug 2011 17:24:07 +0000, Jonathan M Davis wrote:

>> 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?

I don't think we should design the library around shortcomings of the 
compiler.


> Also, can ddoc handle it? I'm not
> sure that a template mixin like that would be properly documented.

The functions would be documented as members of the Path template, and 
we'd have to state in the module introduction that the template itself 
can, for the most part, be ignored unless you really need the extra 
functionality.

The fact that the docs become slightly more convoluted is, of course, an 
argument against my solution.  However, I don't think it outweighs the 
benefits.


> 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.

Again, it doesn't have to be decided upon now.  Adding it later is a non-
breaking change.  Actually, it would probably be a bad idea to do it now, 
when there are only a few days left of the review.

-Lars