On Thu, 03 Mar 2011 10:39:38 -0800, Jonathan M Davis wrote: > 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.
We probably couldn't disagree more. :) I think fncharmatch is a horrible name. On the other hand, basename() is named after the 'basename' UNIX utility, and doesn't mean anything on its own. At least, I've never heard of such a thing as the "base name" of a file, but please prove me wrong. > 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. I have a preference for the longer names, but not a very strong one. I'm not going to oppose the changes if others agree with you. > 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. Good point. > 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). Also a good point. Not only that, most functions should be pure @safe nothrow, but I've completely forgotten to add these annotations! > 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. It's in the examples for extension() and stripExtension(). > 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 Thanks for the feedback! -Lars
