Thread overview | |||||
---|---|---|---|---|---|
|
April 22, 2010 [phobos] std.path cleanup | ||||
---|---|---|---|---|
| ||||
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 |
April 23, 2010 [phobos] std.path cleanup | ||||
---|---|---|---|---|
| ||||
Posted in reply to Lars Tandle Kyllingstad | 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 > > |
April 23, 2010 [phobos] std.path cleanup | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 |
Copyright © 1999-2021 by the D Language Foundation