Proposal for std.path replacement

[Jonathan M Davis]

On Friday 04 March 2011 00:33:58 Lars T. Kyllingstad wrote:
> On Thu, 03 Mar 2011 10:39:38 -0800, Jonathan M Davis wrote:
> > 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.

I have no problem with finding better names than those. I was more saying that 
the names that they have shouldn't be camelcased. They'd be absolutely hideous 
if they were.

As for basename, I'd argue baseName because it's properly camelcased that way 
(and therefore follows Phobos' general naming conventions). I don't find the fact 
that there's a unix utility by that name to be particularly relevant to the 
casing of the name. But regardless, the concept of a file's "base name" is quite 
clear, even if you've never heard of the unix utility efore.

> > 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.

I definitely like descriptive names, and my function names are often long, but I 
do tend to find that long names can get annoying - especially if you have to use 
them often. So, I think that you should generally choose shorter names as long 
as they are appropriately descriptive. A name like stripExt is clear enough - 
especially in context - to work quite well, so the longer name stripExtension is 
unnecessary, whereas ext may not be clear enough and the full name extension 
would probably be better.

> > 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!

Indeed. I should have noticed and mentioned the lack of pure and nothrow as 
well. I haven't generally messed with @safe yet though, since so many critical 
functions in Phobos aren't @safe yet, so you can't really make much @safe. If 
you can though, it's definitely desirable.

> > 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().

Ah, so it is. I missed it. I was looking for something real like .bashrc rather 
than .file, and I glanced over it too quickly to notice it.

- Jonathan M Davis