Open lihaoyi opened 3 days ago
I don't think we want to blur the difference between the two. I think the primary motivation for PathRef
is to have an appropriate content tracker for paths, whereas os.Path
is representing the path itself, but not the content. If we merge both, we will no longer be able to express in an API, what we are interested in. Also the result of tasks may be less specific and may invalidate unnecessary often, e.g. when only the path is needed, but a PathRef
is returned.
If convenience is needed, we could think about adding some convenience API to PathRef
, e.g. a way to assemble sub-paths. But in the end, the explicit .path
might still be what we really want in terms of clarity.
e.g. making one a subtype of the other would remove the need for a lot of tedious
.path
extraction, especially if we provide aShellable
instance for itAlternately, what if we got rid of
PathRef
altogether, and just made the JSON serializer foros.Path
do whatPathRef
does today? We might need to tweak things so e.g. the hashcode is computed from the JSON serialized output rather than calling.hashCode
on the valueNot clear what the best thing to do here, but I think there's definitely room to reduce some friction juggling between
Path
s andPathRef
s