[phobos] RFC: std.path

[Jose Armando Garcia]

On Sun, Jun 12, 2011 at 3:26 PM, Jose Armando Garcia <jsancio at gmail.com> wrote:
> Em 12/06/2011, às 14:00, Lars Tandle Kyllingstad <lars at kyllingen.net>
> escreveu:
>
>> On Sun, 2011-06-12 at 13:36 -0300, Jose Armando Garcia wrote:
>>>
>>> On Sun, Jun 12, 2011 at 12:59 PM, Lars Tandle Kyllingstad
>>> <lars at kyllingen.net> wrote:
>>>>
>>>> On Sun, 2011-06-12 at 12:41 -0300, Jose Armando Garcia wrote:
>>>>>
>>>>> On Sun, Jun 12, 2011 at 12:15 PM, Lars Tandle Kyllingstad
>>>>> <lars at kyllingen.net> wrote:
>>>>>>
>>>>>> On Sun, 2011-06-12 at 11:39 -0300, Jose Armando Garcia wrote:
>>>>>>>
>>>>>>> On Wed, Jun 8, 2011 at 4:29 PM, Lars Tandle Kyllingstad
>>>>>>
>>>>>> These functions are from the old std.path, and I haven't made any
>>>>>> changes to them in my version.
>>>>>>
>>>>>> - toAbsolute()
>>>>>> - toCanonical()
>>>>>>
>>>>>
>>>>> In the comments where you say that it doesn't perform any IO you
>>>>> should add these functions.
>>>>
>>>> Does getcwd() perform any IO on Windows?  AFAIK, on POSIX it just
>>>> queries /proc/self/cwd, which is a virtual file.
>>>>
>>>
>>> The way I look at IO is anything that is external to the process.
>>> Another way to thinking about it is that
>>> toAbsolute()'s and toCanonical()'s result is dependent on state
>>> outside of the process. While the rest of the templates/functions
>>> aren't.
>>
>> The way I've interpreted the "no IO" principle of std.path is "no
>> disk/network IO", since those would come with an enormous performance
>> penalty as compared to in-memory operations.  But maybe you are right.
>>
>>
>>>>> Speaking of which can we add a template
>>>>> called normalize (maybe you can come up with a better name) that does
>>>>> what canonical does but doesn't make it absolute. E.g.:
>>>>>
>>>>> version(windows) assert(normilize("dir/file") == "dir\\file");
>>>>> version(windows) assert(normilize("dir/./file") == "dir\\file");
>>>>> //etc
>>>>
>>>> That sounds like a good idea.  Then I guess normalize("../foo") should
>>>> just return "..\\foo", i.e. leave the ".." unresolved?
>>>>
>>>
>>> It is hard to resolve '..' without looking at the file system when
>>> considering soft/sym link due to multiple parents. if 'somedir' is a
>>> simlink "somedir/../" != ".".
>>
>> That is a matter of choice, I guess.  In both bash and zsh, if I type
>>
>>  cd some_dir/some_symlink/..
>>
>> I end up in some_dir, regardless of where some_symlink is pointing.
>> That is how toCanonical() does things as well, and how I think
>> normalize() should work if I end up adding that.
>
> But most program dont behave this way. For example ls, less and vim don't do
> that. I am okay with resolving symlinks but just take note.

Err. I am okay with resolving "..".