On 9/14/10 19:40 CDT, Jonathan M Davis wrote:
> On Tuesday, September 14, 2010 11:11:16 David Simcha wrote:
>> Funny, I was going to suggest just lumping all three (path, file, stdio).
>
> Well, looking at the docs for std.stdio, it does some quite odd that it and std.file are separate.

Actually std.stdio opens files and writes to them piecewise whereas std.file treats files as a unit. The associated scenarios are quite different.

Andrei

On Wednesday 15 September 2010 05:06:58 SHOO wrote:
> I think that these features should be refined more, too. I am confused that the handling of strings and path are mixed.

A path _is_ a string. It's a string which indicates where on the file system a file is located. All of the functions in std.path are, therefore, string-related. However, they all relate to paths as opposed to strings in general, so I don't see what's mixed about them.

- Jonathan M Davis

(2010/09/16 0:45), Jonathan M Davis wrote:
> On Wednesday 15 September 2010 05:06:58 SHOO wrote:
>> I think that these features should be refined more, too. I am confused that the handling of strings and path are mixed.
>
> A path _is_ a string. It's a string which indicates where on the file system a file is located. All of the functions in std.path are, therefore, string-related. However, they all relate to paths as opposed to strings in general, so I don't see what's mixed about them.
>
> - Jonathan M Davis

That is right.
However, what about vice versa? string is not path in some cases.

For example, the thing which "exists" means may not be a file. (URL,
ISBN, words, system specialized function, and so on. Strings may not
show only a pass.)
The thing which "join" connects may not be a pass. (You cannot guess
result of join("path", "to", "the", "file") is "path/to/the/file" or
"topaththepathfile". And this brings on conflict between std.string.join
and std.path.join)
You cannot be convinced that "getSize" is the capacity of the file. (It
may be the allocated memory size or the NIL terminated string length.)

This is only a part of the examples.
Users have wrong how to use if users will not treat it carefully.

On Thursday, September 16, 2010 04:27:17 SHOO wrote:
> (2010/09/16 0:45), Jonathan M Davis wrote:
> > On Wednesday 15 September 2010 05:06:58 SHOO wrote:
> >> I think that these features should be refined more, too. I am confused that the handling of strings and path are mixed.
> > 
> > A path _is_ a string. It's a string which indicates where on the file system a file is located. All of the functions in std.path are, therefore, string-related. However, they all relate to paths as opposed to strings in general, so I don't see what's mixed about them.
> > 
> > - Jonathan M Davis
> 
> That is right.
> However, what about vice versa? string is not path in some cases.
> 
> For example, the thing which "exists" means may not be a file. (URL,
> ISBN, words, system specialized function, and so on. Strings may not
> show only a pass.)
> The thing which "join" connects may not be a pass. (You cannot guess
> result of join("path", "to", "the", "file") is "path/to/the/file" or
> "topaththepathfile". And this brings on conflict between std.string.join
> and std.path.join)
> You cannot be convinced that "getSize" is the capacity of the file. (It
> may be the allocated memory size or the NIL terminated string length.)
> 
> This is only a part of the examples.
> Users have wrong how to use if users will not treat it carefully.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

That sort of stuff stems from the fact that a path is not its own type. std.path contains functions for dealing with strings that are paths. If the strings that you give it aren't valid paths, then either they won't work or you won't get valid paths out of them (depending on the function and what it's doing). Sure, std.path.join() conflicts with std.string.join(), but they do different things, albeit similar.

Complaining about std.path using strings and that those strings may not be valid paths would be like complaining that std.xml uses strings and that those strings may not be valid xml. The functions are designed for handling strings that are paths, and at least some of them check that the strings they're given are valid paths.

I really don't understand what the problem is. std.path deals with strings that are paths. std.string deals with strings in general. And std.file deals with file operations. They are all quite distinct, even if some function names do overlap (which is one of the reasons that we have modules rather than a global namespace).

- Jonathan M Davis

(2010/09/17 8:03), Jonathan M Davis wrote:
> On Thursday, September 16, 2010 04:27:17 SHOO wrote:
>> (2010/09/16 0:45), Jonathan M Davis wrote:
>>> On Wednesday 15 September 2010 05:06:58 SHOO wrote:
>>>> I think that these features should be refined more, too. I am confused that the handling of strings and path are mixed.
>>>
>>> A path _is_ a string. It's a string which indicates where on the file system a file is located. All of the functions in std.path are, therefore, string-related. However, they all relate to paths as opposed to strings in general, so I don't see what's mixed about them.
>>>
>>> - Jonathan M Davis
>>
>> That is right.
>> However, what about vice versa? string is not path in some cases.
>>
>> For example, the thing which "exists" means may not be a file. (URL,
>> ISBN, words, system specialized function, and so on. Strings may not
>> show only a pass.)
>> The thing which "join" connects may not be a pass. (You cannot guess
>> result of join("path", "to", "the", "file") is "path/to/the/file" or
>> "topaththepathfile". And this brings on conflict between std.string.join
>> and std.path.join)
>> You cannot be convinced that "getSize" is the capacity of the file. (It
>> may be the allocated memory size or the NIL terminated string length.)
>>
>> This is only a part of the examples.
>> Users have wrong how to use if users will not treat it carefully.
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
>
> That sort of stuff stems from the fact that a path is not its own type. std.path contains functions for dealing with strings that are paths. If the strings that you give it aren't valid paths, then either they won't work or you won't get valid paths out of them (depending on the function and what it's doing). Sure, std.path.join() conflicts with std.string.join(), but they do different things, albeit similar.
>
> Complaining about std.path using strings and that those strings may not be valid paths would be like complaining that std.xml uses strings and that those strings may not be valid xml. The functions are designed for handling strings that are paths, and at least some of them check that the strings they're given are valid paths.
>
> I really don't understand what the problem is. std.path deals with strings that are paths. std.string deals with strings in general. And std.file deals with file operations. They are all quite distinct, even if some function names do overlap (which is one of the reasons that we have modules rather than a global namespace).
>
> - Jonathan M Davis

Your opinion is not pertinent. Complaining about std.path using strings of invalid paths is not related.

When user code showed it, you cannot judge it quickly:

class A{
   ...
   File foo()
   {
     return File(join(p, "bar"));
   }
   ...
}

What is "join" meaning? std.stirng.join ? std.path.join ? User-defined
function? Alias?
The name called join is too general to recognize that it is related to a
path of filesystem. (Sure, it is not to have been limited join.)
If it makes a model for path as one way, it is a problem broken off.

And therefore, as for the problem that I explained, example of behavior
of std.xml is totally the other problem.
Rather I think that the behavior of std.xml is extremely right.
If I compare behavior with std.xml, I think std.path should have Path
struct so that std.xml has Document, Item, Elements, etc.
If your opinion was right, std.xml would not have any user-defined types.

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 9/17/10 2:18 PM, SHOO wrote:
> (2010/09/17 8:03), Jonathan M Davis wrote:
>> On Thursday, September 16, 2010 04:27:17 SHOO wrote:
>>> (2010/09/16 0:45), Jonathan M Davis wrote:
>>>> On Wednesday 15 September 2010 05:06:58 SHOO wrote:
>>>>> I think that these features should be refined more, too. I am confused that the handling of strings and path are mixed.
>>>>
>>>> A path _is_ a string. It's a string which indicates where on the file system a file is located. All of the functions in std.path are, therefore, string-related. However, they all relate to paths as opposed to strings in general, so I don't see what's mixed about them.
>>>>
>>>> - Jonathan M Davis
>>>
>>> That is right.
>>> However, what about vice versa? string is not path in some cases.
>>>
>>> For example, the thing which "exists" means may not be a file. (URL,
>>> ISBN, words, system specialized function, and so on. Strings may not
>>> show only a pass.)
>>> The thing which "join" connects may not be a pass. (You cannot guess
>>> result of join("path", "to", "the", "file") is "path/to/the/file" or
>>> "topaththepathfile". And this brings on conflict between std.string.join
>>> and std.path.join)
>>> You cannot be convinced that "getSize" is the capacity of the file. (It
>>> may be the allocated memory size or the NIL terminated string length.)
>>>
>>> This is only a part of the examples.
>>> Users have wrong how to use if users will not treat it carefully.
>>> _______________________________________________
>>> phobos mailing list
>>> phobos at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/phobos
>>
>> That sort of stuff stems from the fact that a path is not its own
>> type. std.path
>> contains functions for dealing with strings that are paths. If the
>> strings that
>> you give it aren't valid paths, then either they won't work or you
>> won't get
>> valid paths out of them (depending on the function and what it's
>> doing). Sure,
>> std.path.join() conflicts with std.string.join(), but they do
>> different things,
>> albeit similar.
>>
>> Complaining about std.path using strings and that those strings may
>> not be valid
>> paths would be like complaining that std.xml uses strings and that
>> those strings
>> may not be valid xml. The functions are designed for handling strings
>> that are
>> paths, and at least some of them check that the strings they're given
>> are valid
>> paths.
>>
>> I really don't understand what the problem is. std.path deals with
>> strings that
>> are paths. std.string deals with strings in general. And std.file
>> deals with file
>> operations. They are all quite distinct, even if some function names
>> do overlap
>> (which is one of the reasons that we have modules rather than a global
>> namespace).
>>
>> - Jonathan M Davis
>
> Your opinion is not pertinent. Complaining about std.path using strings of invalid paths is not related.
>
> When user code showed it, you cannot judge it quickly:
>
> class A{
> ...
> File foo()
> {
> return File(join(p, "bar"));
> }
> ...
> }
>
> What is "join" meaning? std.stirng.join ? std.path.join ? User-defined
> function? Alias?
> The name called join is too general to recognize that it is related to a
> path of filesystem. (Sure, it is not to have been limited join.)
> If it makes a model for path as one way, it is a problem broken off.
>
> And therefore, as for the problem that I explained, example of behavior
> of std.xml is totally the other problem.
> Rather I think that the behavior of std.xml is extremely right.
> If I compare behavior with std.xml, I think std.path should have Path
> struct so that std.xml has Document, Item, Elements, etc.
> If your opinion was right, std.xml would not have any user-defined types.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

Le 2011-01-02 ? 19:01, Andrei Alexandrescu a ?crit :

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

I don't mind much having paths as strings, except for one thing:

What I dislike currently is that std.path always implement the OS filesystem path syntax. In some code dealing with the web I had to implement my own path functions to deal with URL paths (using std.path would break on Windows). So having distinct types to deal with different kinds of paths would probably be helpful.

That said, perhaps handling of URIs doesn't belong in std.path...

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/

On Sunday 02 January 2011 16:01:47 Andrei Alexandrescu 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.

I'm sure that it depends on the use case, but if you're doing a lot of operations on paths which would involve adding, removing, or renaming directories, then having a Path struct of some kind which essentially held a linked list of the pieces of the path could be beneficial. If you're having to constantly search for the Xth separator in the string and the like - especially if you're then having to create a new string with changes - it could be a bit expensive to deal with just strings. However, any time that you then need to actually use the path - like opening a file or whatnot - you'd need to concatenate the whole thing together, and doing that a lot could get expensive too.

For the general use case, I think that strings work just fine and that having a Path struct would be unnecessary overhead. There are use cases where it could be useful, so it might be useful to have a Path struct for such cases (what Boost has is rather nice from what I recall), but that isn't the typical case.

The one really nice thing about using a Path struct that I can think of is that it makes errors related to different separators less likely. The separator would generally be abstracted away in the user code and then dealt with appropriately by the Path struct when turned into string form for OS calls and the like. It might also help cases where you actually want to use the separator in a file name, though that's generally a bad idea, even if it can be done.

I really liked Boost's path stuff last time I messed with it, and having something similar in Phobos would be cool, but I would worry that that's just overkill for the average case. Certainly, if we have a Path struct of some kind, it needs to work with strings well and easily, or it's going to be a problem.

Personally, I'm not sure how much I care either way. A solid Path struct could be very cool, but it also could be overkill.

- Jonathan M Davis

On Sunday 02 January 2011 16:18:20 Michel Fortin wrote:
> Le 2011-01-02 ? 19:01, Andrei Alexandrescu a ?crit :
> > 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.
> 
> I don't mind much having paths as strings, except for one thing:
> 
> What I dislike currently is that std.path always implement the OS filesystem path syntax. In some code dealing with the web I had to implement my own path functions to deal with URL paths (using std.path would break on Windows). So having distinct types to deal with different kinds of paths would probably be helpful.
> 
> That said, perhaps handling of URIs doesn't belong in std.path...

URIs are their own beast, I think. They have their own rules about what is and isn't allowed in them and what separators they use. Also, the fact that you can have arguments in them and the like makes them distinctly different from file system paths. Even though there is definitely some overlap, what exactly you're trying to do with them and how you use them is definitely different. That being said, it would probably good to have some decent URI stuff in Phobos at some point. Having some HTTP stuff would be good too. In any case, I wouldn't consider it to be a good idea to mix file system paths and URIs.

- Jonathan M Davis

Agreed. So that doesn't count as an argument for a Path type.

Andrei

On 1/2/11 7:33 PM, Jonathan M Davis wrote:
> On Sunday 02 January 2011 16:18:20 Michel Fortin wrote:
>> Le 2011-01-02 ? 19:01, Andrei Alexandrescu a ?crit :
>>> 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.
>>
>> I don't mind much having paths as strings, except for one thing:
>>
>> What I dislike currently is that std.path always implement the OS filesystem path syntax. In some code dealing with the web I had to implement my own path functions to deal with URL paths (using std.path would break on Windows). So having distinct types to deal with different kinds of paths would probably be helpful.
>>
>> That said, perhaps handling of URIs doesn't belong in std.path...
>
> URIs are their own beast, I think. They have their own rules about what is and isn't allowed in them and what separators they use. Also, the fact that you can have arguments in them and the like makes them distinctly different from file system paths. Even though there is definitely some overlap, what exactly you're trying to do with them and how you use them is definitely different. That being said, it would probably good to have some decent URI stuff in Phobos at some point. Having some HTTP stuff would be good too. In any case, I wouldn't consider it to be a good idea to mix file system paths and URIs.
>
> - Jonathan M Davis
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos