[phobos] next release (meaning of path)

[SHOO]

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