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.

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()


3. Add some useful stuff, like the toCanonical() function I have in my personal library (it's like rel2abs, except it also resolves ../ and ./).


4. Change the type of sep, altsep, etc. to immutable string.  (Or is there a good reason why they're all _static_ arrays?)


5. Get rid of the legacy stuff (specifically, the getBaseName and getDirName aliases).  Now's a good a time as any.


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

   * On POSIX, getExt("/tmp/.foo") returns "foo", should be ""
     (it's the name of a hidden file, not an extension).



Whatcha think?

-Lars

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.

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

>
>
> 3. Add some useful stuff, like the toCanonical() function I have in my personal library (it's like rel2abs, except it also resolves ../ and ./).

Sounds good.

>
>
> 4. Change the type of sep, altsep, etc. to immutable string.  (Or is there a good reason why they're all _static_ arrays?)

Sounds good.

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

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

>
>
>
> Whatcha think?
>
> -Lars
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
>

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