Proposal for std.path replacement

[Jonathan M Davis]

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