Proposal for std.path replacement

[Nick Sabalausky]

""Jérôme M. Berger"" <jeberger at free.fr> wrote in message 
news:il0f04$2ts8$1 at digitalmars.com...
> This does not make sense because there is no way to tell whether
>"foo/bar" is intended as a file name or a dir name. IMO the only
>sensible thing to do is to split on the last path separator:
>everything to the right is the base name (or everything if there is
>no separator) and everything to the left is the dir name. This has
>the two very important advantages:
>
>- It is a simple rule, so is easy to remember;`
>

But it doesn't have simple consequences. If I'm trying to refer to a 
particular directory there's a good chance it could be either "/foo/bar" or 
"/foo/bar/" (and the latter is *not* typically thought of as a shorthand for 
"/foo/bar/."). Those are conceptually the *exact same thing*, but with the 
"last slash" rule you suggest, they have wildy different effects when passed 
to certain std.path functions. Most notably, if it's a path with a trailing 
slash, then dirName **no longer returns the directory that *contains* the 
element specified**. It just returns the element itself *instead* of its 
containing directory.

So, since certain functions would have notably different effects with and 
without a trailing slash, and the trailing slash may or may not have been 
given (since the two styles are typically thought of as interchangable), 
every time you call a std.path functions the "last slash" rule would force 
you to go through these steps:

1. Remember if the function you're using is one that's affected.

2. If so, decide which semantics you want.

3. Detect if the "trailing-slashness" of your string matches the semantics 
you want. Which may, in fact, be impossible: If the semantics you desire 
dictate a trailing slash on directories, and your string lacks a trailing 
slash then the *only* way to proceed correctly is to know whether it's 
intended to be a file or a directory, and you don't always know.

4. Coerce your string to match the desired semantics, if possible.

5. Finally call the dammed function.

>- It does not need the path to exists and it does not need to know
>whether the path is intended as a file or dir.

As I described above, it will sometimes need to know.

Alternatively, the current behavior of Lars's proposed std.path is, to the 
human mind, an equally simple rule and therefore equally simple to remember: 
That last element is the baseName and all the elements before it are the 
dirName.

In contrast to the "last slash" rule, this "last element" rule behaves 
exactly the same regardless of whether a trailing slash was appended or 
omitted and *actually* never needs to know if the path is intended as a file 
or dir. So the five steps above get condensed down to one:

1. Just call the dammed function.

I'll admit, the "last element" behavior of Lars's proposed std.path did 
raise a small red flag to me at first. But the more I think about it, the 
more I think it's the best way to go.