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
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
