Deno: Consider adding a path class to the standard library

[cjbassi]

Currently there is a path module in the Deno standard library, but it's not architectured in an OOP way and the functions are stringly typed. This is similar to how python used to do path operations with the os module, and then they replaced it with the pathlib module which works in a more object-oriented way with methods instead of functions and with a strongly typed path type. Rust also has a path module in the standard library and they ended up basing it on pythons pathlib module. Thanks!

[nayeemrmn]

A minimal, primitive-based interface is better in general, but especially important for Deno where for a while we'll be trying to accommodate lots of ported-over libraries. This would get in the way.

Also, the end result of putting this in std is having built-in APIs still using strings but std using Path.

[ry]

I do really like the Rust path class...

[cjbassi]

I thought about it some more, and I think there might be some ergonomic issues with functions that take a path class since they would have to specify Path | string. I'm not super familiar with typescript, so I'm not sure if that would cause any issues with functional implementations either.

[cdaringe]

@cjbassi, looks like rust Path methods operate on other Path instances, then deserialize back out to strings. prob no need to | string

[cjbassi]

Well the functions in the rust standard library that take a path actually take a AsRef<Path> which can be a bunch of things including a Path or string.

[bartlomieju]

Available at https://deno.land/std/path

[cjbassi]

@bartlomieju I'm aware there is a path module, but the issue is whether we should add a path class instead of having a bunch of separate functions, so I don't think this issue is resolved.

[caspervonb]

I'm for this, been thinking about it for a while but haven't sat down to flesh it out.

I think it can pan out nicely, it mirrors the URL in a way and can be implicit with valueOf (design decision to be made there).

[axetroy]

FP or OOP? This is a long-standing dispute.

Personally, I like functional instead of class.

Functions are easy to test and combine，and it's more lower-level than OOP. The class has internal state, which is difficult to predict.

[nayeemrmn]

I do really like the Rust path class...

I think it can pan out nicely, it mirrors the URL in a way and can be implicit with valueOf (design decision to be made there).

Again, the above references are built-in. This would not be. Let's appreciate what that would mean. Do you expect people to declare public argument signatures with Path, forcing a dependency on anyone who wants to use it? Or do you have to construct and stringify it at entry and exit of any API? Let's not start systematically using valueOf() like it's Rust's From or something. That's not how it works. It doesn't really work at all.

Take a look at https://github.com/WICG/native-file-system. The browser will have built-in functions that take paths as strings. I don't need to say how this change affects browser-compatibility because we've had that conversation many times already: https://github.com/denoland/deno/issues/4052#issuecomment-589254004, https://github.com/denoland/deno/pull/6252#issuecomment-680878871. Let's just stick to primitive types and a functional style.

[kitsonk]

I agree with @nayeemrmn but the File API and the Native FileSystem all use strings. If the browser had a Path class, like they had a Url class, then it might make sense, but it doesn't, so we should avoid it, as it is something unique that we end up dragging around that is effectively already solved. This of course doesn't prevent someone from making a Path class as part of the community.

[caspervonb]

Anyway, designing and considering such a class it's not something I have the bandwith to explore right now so not championing it. Just think it might be interesting to explore.