Fix IO::Path.absolute/.relative to return IO::Path

[ugexe]

http://doc.perl6.org/type/IO::Path technically says a new IO::Path, so someone more familiar with the path caching may want to take it one step further.

[niner]

The speculations use a Str return type for .absolute and .relative. Though I'd personally like these methods to return IO::Path objects for consistency if nothing else, this would be a backwards incompatible change that should not be made lightly this side of christmas. So I'd say we first have to figure out, how to implement a 6.d version where this change can be included.

[ugexe]

abspath would seem to serve no purpose in that case as both return the same string with 0 arguments

[niner]

abspath is also missing from the speculations. Probably because it's redundant and an implementation detail really.
I would actually like to know what lizmat++'s plan for that in the newio branch was.

[Leont]

I'm surprised (and somewhat horrified) it does this :-(

[AlexDaniel]

IRC discussion: http://irclog.perlgeek.de/perl6/2016-08-04#i_12967325

[AlexDaniel]

Old bug report: https://rt.perl.org/Ticket/Display.html?id=126262

[zoffixznet]

Rejecting this.

The .absolute/.relative methods are basically a way to fine-tune how to an IO::Path is stringified. Since relative IO::Paths are relative to their $!CWD attribute and not the current $*CWD there's no tangible difference between absolute and relative IO::Path objects, so returning an IO::Path object from these methods is pointless.

-- IO grant

[Leont]

The .absolute/.relative methods are basically a way to fine-tune how to an IO::Path is stringified. Since relative IO::Paths are relative to their $!CWD attribute and not the current $*CWD there's no tangible difference between absolute and relative IO::Path objects, so returning an IO::Path object from these methods is pointless.

I would disagree. For one I would expect their stringification to be different (and consider this useful).

[zoffixznet]

Stringification with methods other than .absolute/.relative does not take $!CWD into account, so these methods are the only ones you can use for that purpose, if you wish to reliably use the stringified results as paths to access some filesystem entity.

It might've been better to make .Str not have this caveat and work as either .absolute or .relative, but I can think of reasons to why keeping it the way it is is DWIMMY. And such a change was on the table for the IO grant work, but was ultimately rejected.