On Thursday, March 03, 2011 08:29:00 Lars T. Kyllingstad wrote: > As mentioned in the "std.path.getName(): Screwy by design?" thread, I > started working on a rewrite of std.path a long time ago, but I got > sidetracked by other things. The recent discussion got me working on it > again, and it turned out there wasn't that much left to be done. > > So here it is, please comment: > > http://kyllingen.net/code/ltk/doc/path.html > https://github.com/kyllingstad/ltk/blob/master/ltk/path.d > > Features: > > - Most functions work with all string types, i.e. all permutations of > mutable/const/immutable(char/wchar/dchar)[]. Notable exceptions are > toAbsolute() and toCanonical, because they rely on std.file.getcwd() > which returns an immutable(char)[]. > > - Correct behaviour in corner cases that aren't covered by the current > std.path. See the other thread for some examples, or take a look at the > unittests for a more complete picture. > > - Saner naming scheme. (Still not set in stone, of course.)
Some comments on names: 1. They should properly camelcased. fcmp, fnccharmtach, and fnmatch are probably okay, but basename should definitely be baseName. 2. Please shorten the Separator in the names to Sep (i.e. dirSep, pathSep, and isDirSep). They're just as clear that way and less annoyingly long. Similarly, I'd rename currentDirSymbol to currDirSymbol - or maybe even have currDirSym and parentDirSym. 3. I'd prefer dirName to directory. It's shorter, closer to what was there before, and a better name IMHO. directory makes me wonder if it's checking whether the name is a directory or not (which is what std.file.isDir does). 4. It might be better to short extension/Extension to ext/Ext, but that works better with functions like stripExtension (stripExt), then it would extension (ext) by itself, and if we wanted complete consistency, then changing Extension to Ext would mean changing extension to ext, which wouldn't really be desirable. I'd still be very tempted to rename the xExtension functions to xExt though. Extension is unnecessarily long. 5. setExtension might be better as replaceExtension, since set tends to imply that you're doing the change to the passed in string rather than just returning a new string with the changes. 6. I'd strongly suggest making most of the functions properties (though that would require changing the examples). Functions which are nouns (such as drive or extension) really should be properties, otherwise they shouldn't have names which are nouns. basename/baseName is a funny one though since it's a noun and really should be a property, but it does have a version which takes an extra parameter, so I'm not sure what to do with that one. Unfortunately, for some reason, at the moment you can't overload property function with a non-property function (I keep meaning to open an enhancement request on that). As far as examples go, assuming that you made it so that .bashrc is a file with a base name of .bashrc and no extension rather than a file with no base name and an extension of bashrc (I haven't looked at the implementation at all yet, so I don't know what you did with that), then you really should put it (or an example like it) in the examples. At a first glance, it looks good overall, but I really think that the noun functions should become properties or have their names changed and that some of the names really should be shortened. We want properly descriptive names, but it doesn't take that much for a longer name to get irritating. - Jonathan M Davis
