[phobos] RFC: std.path

[Jose Armando Garcia]

On Wed, Jun 15, 2011 at 5:22 AM, Lars Tandle Kyllingstad
<lars at kyllingen.net> wrote:
> On Sun, 2011-06-12 at 15:35 -0300, Jose Armando Garcia wrote:
>> 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 "..".
>
> I have thought some more about this, and I think I will simply remove
> toCanonical() and replace it with normalize().  After all,
>
>    auto canonicalPath = normalize(toAbsolute(path));
>
> What do you think?
>
> -Lars
>

The idea looks good to me but the naming seems off to me. I don't like
toAbsolute. To me to...() methods imply conversion of type. Think
'toString', which takes some object and makes it a string. Or the
template function 'to'... Maybe just 'absolute' is fine.