[phobos] next release (meaning of path)

[Andrei Alexandrescu]

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