[phobos] next release (meaning of path)

[Jesse Phillips]

On Mon, Jan 3, 2011 at 6:55 PM, spir <denis.spir at gmail.com> wrote:
> On Mon, 3 Jan 2011 14:42:01 -0800
> Jesse Phillips <jesse.k.phillips at gmail.com> wrote:
>
>> * Converting to the proper sep
>> * getBaseName(getName(file)) will give just the filename and no path
>> when there is no extension, switching the calls gives you nothing.
>> * A quoted path is sometimes valid, and some times not. Namely making
>> system calls needs the quotes or escaped spaces, while std.file
>> expects none of that.
>> * It should be easy to convert one OS path style to another. (Ignoring
>> drive letter)
>
> All of these features, together with ones already present in std.path, typically are what a type is meant for, I guess. Indeed, you can also have a bunch of free functions implicitely taking a string-meant-to-be-a-path as first argument; but functionally _and_ conceptually, it's the same thing. Or do I misinterpret?
> Then if i'm right, the debate falls down to a question of programming style preference, or what? One could argue that no notion at all requires a type (an explicite type). But code clarity is also a feature (that some dose of OO style often helps providing).

I do not have a strong opinion on which it should be. But I do think
that anything that operates on a path should only accept one (no
overloading with Path and string).

I think all we really need is to take a given path which could be in
any format and have it converted to a standard form. From their most
operations are not difficult to handle. For example if you know it
correctly uses the system separator:

auto arr = std.algorithms.splitter(path, sep);
auto name = path[0..std.string.lastIndexOf(".")];

If you have an array of path elements:

auto path = std.string.join(arr, sep);
auto name = arr[$-1][0..std.string.lastIndexOf(".")];

These two examples have very different behavior and I don't claim we
should remove the functions getName and such, but that having a
consistent representation of a path means you can write deal with
anomalies in a path more easily. For one thing I don't always agree
with what getName would return as the name depending on what I am
trying to do with the name, especially since it is OS dependent (not
bad, but will give different results).

My examples where you'd want to convert from one OS style to another
is when accepting user input. For a single application it is easy to
write the code in one place and use that, but across multiple
applications that is what a module is for and it makes sense that
std.path would be the place to find such a thing.

The only issue I see with using strings is that calls to things like
std.file.File or getName... should expect the input to be a properly
formatted path. If that is a string then it should be formatted for
the OS. And this leads to errors with hard coded string and I always
use / even on Windows.