Proposal for std.path replacement

[Lars T. Kyllingstad]

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