> Should IO behave like value objects?
The current behaviour is what we want to keep (this also now being far on the
other side
of The Christmas), so I'll close this RFC.
> However, it seems to use .Str rather than .abspath to compare them
Currently, we go through the default Mu `eqv` and so it compares *all* of
IO::Path's attributes.
The reason `say "foo".IO eqv "/tmp/foo".IO;` compares False is because the
objects contain
different $.path attributes.
All the other proposals in the ticket talk about different ways of verifying
the two IO::Path objects
point to the same filesystem object. However, there's no good way of doing that
while guaranteeing
the comparison will hold true after the comparison (i.e. when the user wishes
to use that result).
So it's not really a generalizable behaviour that we want to do under the hood,
but rather something that
the user should be explicitly doing.
- .abspath (now .absolute) doesn't access the filesystem, so two paths with
different .abspaths can
still reference the same filesystem object. The user can still use this
behaviour via smartmatching
- we can kick it up a notch and do .resolve, but by default that will stop as
soon as it hits an path part
that doesn't exist, and from that point we're back to the same issue as with
.absolute
- we can use .resolve with :completely arg, but that will make paths that
reference non-existent objects
uncomparable
- but even with paths that do .resolve(:completely) we hit the temporal issue
Bart mentioned. The filesystem
condition may change the moment we finish doing our checks, or even in the
middle of our check, resulting
in incorrect answers.
While the same issue exists with methods such as IO::Path.e, I think eqv
comparison should go further than
just ensuring resolved path point to the same filesystem object, as there are
cases where it matters. For example,
stringification via .Str method ignores .CWD attribute or stuff like $*CWD
variable often needs objects with
absolute $.path attributes. So the values of individual attributes are more
important than what the IO::Path points to.
So in summation, I think the current behaviour of treating IO::Path as any
other object, as we've been doing
since first release in this case is most desirable behaviour.
