std.path review: second update

Lars T. Kyllingstad public at kyllingen.NOSPAMnet
Mon Aug 1 09:37:14 PDT 2011


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.

-Lars


More information about the Digitalmars-d mailing list