[phobos] std.path cleanup

[Lars Tandle Kyllingstad]

Walter Bright wrote:
> Lars Tandle Kyllingstad wrote:
>> I have a few suggestions for improvements to std.path, and if people 
>> agree, I'll be happy to implement them:
>>
>>
>> 1. Cross-platform path handling:
>>
>> Since most of std.path only deals with strings, and therefore doesn't 
>> perform any OS-specific operations, there is really no reason to 
>> completely hide the Windows path handling stuff from POSIX users and 
>> vice versa.
>>
>> I therefore propose to put the Windows stuff in a WindowsPath 
>> namespace and the POSIX stuff in a PosixPath namespace, implemented as 
>> structs with only static members.
> 
> Aack, I think this approach just makes things more complicated.

Slightly more so for the library writer, yes, but not for the user. 
Note that I proposed that the functions stay at module level, but as 
aliases of functions for the current system.

The benefit is that if someone wants to manipulate POSIX paths on a 
Windows system -- in an FTP client, say -- they can now prefix the 
relevant functions with PosixPath.

Even for the library writer, putting the Windows stuff in a WindowsPath 
struct isn't that much worse than putting it in a version(Windows) block.


>> The module-level functions stay -- after all, a POSIX user will want 
>> to deal with POSIX paths most of the time -- but now as aliases of 
>> either PosixPath or WindowsPath member functions, depending on which 
>> OS the library is compiled for.
>>
>>
>> 2. Consistent naming:
>>
>>   sep       -> dirSeparator
>>   pathsep   -> pathSeparator
>>   isabs()   -> isAbsolute()
>>   rel2abs() -> toAbsolute()
>>   getExt()  -> extension()
> 
> Don't want to break existing code.

This I really don't understand.  Existing code has been broken in almost 
every release, and I believe I've seen both Andrei and Don write on the 
NG that "it's only the language that needs to be frozen now, there's no 
big hurry to fix Phobos".  Also,

  - The new std.complex will break code.

  - I'm pretty sure the new std.bigint breaks some code.

  - The new operator overloading *really* broke a lot of code.
    Actually, in Phobos, the new bigint and complex modules seem to
    be the only ones that use the new scheme.

...and the list goes on.

I believe it is important to fix the inconsistent naming scheme that 
exists in parts of Phobos, and there is no time like the present.  As 
long as nothing breaks silently, I don't see it as a problem.


>> [...] 
>>
>> 5. Get rid of the legacy stuff (specifically, the getBaseName and 
>> getDirName aliases).  Now's a good a time as any.
> 
> What's wrong with them?

They are just aliases of functions in the same module:

   string basename(...) { ... }
   alias basename getBaseName;

   string dirname(...) { ... }
   alias dirname getDirName;

The documentation specifically states that they are only there for 
backward compatibility.


>> 6. Fix bugs.  Some are in Bugzilla, and there are a couple which I've 
>> found quite recently but haven't gotten around to reporting yet:
>>
>>   * join("", "foo") returns "/foo", should be "foo".
> 
> Ok.
> 
>>
>>   * On POSIX, getExt("/tmp/.foo") returns "foo", should be ""
>>     (it's the name of a hidden file, not an extension).
> 
> What is the pattern that separates hidden file from extension?

http://en.wikipedia.org/wiki/Hidden_file_and_hidden_directory#Unix_and_Unix-like_environments

The convention is that if the filename starts with a dot, the file is 
hidden and the name, or the "meaningful name", of the file is what 
follows the dot.

That's why I would define getExt as follows:

   getExt(".foo")     -->  ""
   getExt("foo")      -->  ""
   getExt("foo.bar")  -->  "bar"
   getExt(".foo.bar") -->  "bar"

-Lars