On Monday 03 January 2011 07:43:27 Andrei Alexandrescu wrote:
> On 1/3/11 6:42 AM, Steve Schveighoffer wrote:
> > Would it be enough to have a function that takes a string (or
> > inout(char)[] if possible) and returns a string[] with the path
> > elements?  Also, a function to do the reverse.
> 
> Problem is I've seldom been in a situation in life where I could find use for such a function. Most of the time I want basename, dirname, and if applicable drive. I don't want to dissect the entire dirname.

When manipulating a file hierarchy, I have found it useful to have the path as a list of directories or something similar. However, most programs don't do that sort of thing. All they usually care about is handling a particular file. And that usually amounts to simply opening it for reading or writing and then closing it. Most programs are worried about files, not paths. The ones which _are_ worried about manipulating paths then find it useful to have fancier constructs to work with, but most programs don't need that sort of thing.

Much as I have found path types to be useful at times, they can definitely be a bit burdensome for simple operations, and simple operations are all that the vast majority of the programs out there really care about. So, I'm tempted to say that a path type just isn't worth the bother in std.path and leave it to a third party library for those who really care. But perhaps someone will be able to come up with a solid argument in favor of a specialized path type. I know that there are D users who definitely want one. I don't know if there are very many such folks though.

- Jonathan M Davis

On Mon, 3 Jan 2011 07:57:24 -0800
Jonathan M Davis <jmdavisProg at gmx.com> wrote:

> Much as I have found path types to be useful at times, they can definitely be a bit burdensome for simple operations, and simple operations are all that the vast majority of the programs out there really care about. So, I'm tempted to say that a path type just isn't worth the bother in std.path and leave it to a third party library for those who really care.

As an intermediate solution, why not let standard _file_ operations have plain string pathes as parameters, but provide a Path type in std.path. Anyway, it won't bother you if let it alone ;-)

An even lighter alternative would be to define
	alias string[] Path;
then (re)write all path functionality funcs as pseudo-methods taking a string[] as first arg, to benefit from the "unversal func call syntax" (which you like so much, and myself as well), that currently works only for arrays. [Except for the pseudo-constructor.]
Worth exploring?

Denis
-- -- -- -- -- -- --
vit esse estrany ?

spir.wikidot.com

On 1/3/11 10:40 AM, spir wrote:
> On Mon, 3 Jan 2011 07:57:24 -0800
> Jonathan M Davis<jmdavisProg at gmx.com>  wrote:
>
>> Much as I have found path types to be useful at times, they can definitely be a bit burdensome for simple operations, and simple operations are all that the vast majority of the programs out there really care about. So, I'm tempted to say that a path type just isn't worth the bother in std.path and leave it to a third party library for those who really care.
>
> As an intermediate solution, why not let standard _file_ operations have plain string pathes as parameters, but provide a Path type in std.path. Anyway, it won't bother you if let it alone ;-)
>
> An even lighter alternative would be to define
> 	alias string[] Path;
> then (re)write all path functionality funcs as pseudo-methods taking
> a string[] as first arg, to benefit from the "unversal func call
> syntax" (which you like so much, and myself as well), that currently
> works only for arrays. [Except for the pseudo-constructor.] Worth
> exploring?

Honestly, I don't think so. Global aliases like that are not all that great because they suggest a type with only path-specific primitives whereas in reality it's not quite all that.

I agree that sometimes you could use a broken-down path (e.g. per Steve's examples) but as Steve also said they are not commonly encountered.


Andrei

I do not know of a good reason for having a Path type. However I do believe much can be added to help with manipulated paths. Here are some issues I've had.

* 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)

On Sun, Jan 2, 2011 at 4:01 PM, Andrei Alexandrescu <andrei at erdani.com> wrote:
> Let's have a brief vote. Do you think we should have a string-like structure Path in std.path? What primitives should it have?
>
> I'm fine using strings, but I could be convinced to use a Path type if it had some compelling advantages.
>
>
> Andrei

On Monday 03 January 2011 14:42:01 Jesse Phillips wrote:
> I do not know of a good reason for having a Path type. However I do believe much can be added to help with manipulated paths. Here are some issues I've had.
> 
> * 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)

A fancier feature would be to have a function which converts a file name to one which is valid for the current OS. Which characters are valid does vary somewhat from file system to file system, but it's OS-specific enough that it can be done. Windows OSes have a specific set of characters that they disallow regardless of the underlying file system, and Linux file systems disallow the null character and sometimes / (so, if you just assume that the null character and / are the only disallowed characters, you should be fine). I'm not sure what Mac OS X does though. In any case, having a function which will convert characters if necessary to make the file name valid for the current OS would be useful for cross-platform compatability, and it doesn't require a path type.

If we're looking to try and abstract out some of the path stuff a bit better without having a separate path type, then having a function like Haskell's combine, which concatenates two parts of a path with the appropriate separator (so, effectively part1 ~ sep ~ part2) would help (it would clean up code too, though you obviously don't _need_ such a function, since we _can_ just concatenate with sep). There are probably other, similar functions that we could add which would help with abstracting out some of the system-specific, path pain without needing a separate path type.

- Jonathan M Davis

I discussed this in the past with a colleague (from the ng I think). The conclusion was that the sliver of users who need facilities to convert path formats from one OS to another is extremely thin.

Andrei

On 1/3/11 5:13 PM, Jonathan M Davis wrote:
> On Monday 03 January 2011 14:42:01 Jesse Phillips wrote:
>> I do not know of a good reason for having a Path type. However I do believe much can be added to help with manipulated paths. Here are some issues I've had.
>>
>> * 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)
>
> A fancier feature would be to have a function which converts a file name to one
> which is valid for the current OS. Which characters are valid does vary somewhat
> from file system to file system, but it's OS-specific enough that it can be done.
> Windows OSes have a specific set of characters that they disallow regardless of
> the underlying file system, and Linux file systems disallow the null character and
> sometimes / (so, if you just assume that the null character and / are the only
> disallowed characters, you should be fine). I'm not sure what Mac OS X does
> though. In any case, having a function which will convert characters if
> necessary to make the file name valid for the current OS would be useful for
> cross-platform compatability, and it doesn't require a path type.
>
> If we're looking to try and abstract out some of the path stuff a bit better without having a separate path type, then having a function like Haskell's combine, which concatenates two parts of a path with the appropriate separator (so, effectively part1 ~ sep ~ part2) would help (it would clean up code too, though you obviously don't _need_ such a function, since we _can_ just concatenate with sep). There are probably other, similar functions that we could add which would help with abstracting out some of the system-specific, path pain without needing a separate path type.
>
> - Jonathan M Davis
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

On Mon, 3 Jan 2011 14:42:01 -0800
Jesse Phillips <jesse.k.phillips at gmail.com> wrote:

> I do not know of a good reason for having a Path type. However I do believe much can be added to help with manipulated paths. Here are some issues I've had.
> 
> * 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).


Denis
-- -- -- -- -- -- --
vit esse estrany ?

spir.wikidot.com

On Monday 03 January 2011 15:32:09 Andrei Alexandrescu wrote:
> I discussed this in the past with a colleague (from the ng I think). The conclusion was that the sliver of users who need facilities to convert path formats from one OS to another is extremely thin.

I've definitely run into it. The main problem being that it's very easy to have file names which are legal on Linux but illegal on Windows. Now, unless you're writing a program that's specifically looking to convert file names from one naming scheme to another, then the odds are that it won't be an issue, because the program will likely only be dealing with files that's been given on the current system and those will obviously have correct file names. So, it wouldn't surprise me in the least if the number of programmers who actually needed to worry about whether a file name that they're dealing with is legal on the current OS or on another OS is probably fairly small. It _would_ be useful to have functions to deal with that though. It's just that it wouldn't be a particularly high priority issue to add that sort of thing, and if std.path were particularly cluttered (which I don't think that it is), then adding those sort of functions would probably be a bad idea. I do think that they'd be nice to have though.

- Jonathan M Davis

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.