""Jérôme M. Berger"" <jeber...@free.fr> wrote in message news:il0f04$2ts8$1...@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.