Thanks! But if Pathname simply delegates to File or FileUtils, in its entirety, then I don't see a lot of reasons to include this. I believe Ruby's standard library grew organically and has a lot of duplicated functionality (for example Process and Open3), and in Crystal we try not to have too much of that.

FWIW, [Python recently added something extremely similar]. It's just a lot more convenient to do stuff with objects instead of overly nested calls, and it also lets you do stuff like path1 / path2 for joining paths.

Pathname does in fact delegate many of its methods, but these are all just convenience methods. Its role is the representation of a path. This is a concept, which does not exist when using the functions from Dir, File and FileUtils.

In ruby AFAIK, the File- and Dir functions which are working with filenames as arguments are trying to convert them with #to_path first. Instead of the convenience call Pathname("foo.txt").read, File.read(Pathname("foo.txt")) should work as well. This way around the role might be clearer.

The benefit, as @kirbyfan64 pointed out, is the dealing with objects and methods instead of strings and functions. For visualization image a method #auto_annotate(input : IO, cache : IO, output : IO):

# Settings
input_file = "./src/test.cr"
annotation_dir = "./annotations"
cache_dir = "/tmp"

# Classic
input_io = File.open(input_file)
cache_io = File.open(File.join(cache_dir, File.basename(input_file)))
annotation_io = File.open(File.join(annotation_dir, File.basename(input_file, ".cr") + ".html"))

# Pathname (assuming the 3 settings vars are Pathnames)
file = file.open
cache_io = (cache_dir / input_file.basename).open
annotation_io = (annotation_dir / input_file.basename.ext(".html")).open

The only function which is handling files in the example is #open, all other function are related to paths, which are used by directories as well.

Maybe its a idea to implement a class Path which is buildable like rubys Pathname and move only the path related stuff from File to it. The core methods should then rely on this class instead of plain strings.

As further convrnience we could add another class or shard which combines Path, Dir, File and FileUtils, like Pathname does.

input_file = input_file.to_path
input_io = File.open(input_file.to_path)
cache_io = File.open(cache_dir.to_path / input_file.basename)
annotation_io = File.open(annotation_dir.to_path / input_file.basename.ext(".html"))

Looking at the implementation, Pathname does nothing but delegate to other types. This falls into our "don't duplicate" policy. We want to avoid having many ways to deal with a single problem.

We already have File + Dir and FileUtils which are different because one is more idiomatic and deals with single resources, when the other looks like a shell (cosmetic) and allows operating on many files at once (feature).

This explains why we may be reluctant to add a 3rd solution, which is purely cosmetic and doesn't bring something new.

I think there is value in Pathname abstraction. I like the type safety it can offer avoiding Strings if you want.

But since there are some doubts to add it I would suggest to create a shard, have a mature implementation and if that end up better or more used we can think of adding it to std lib or to the organization if the author want it.

I am personally not against it, for example the / and + methods are nice, but since this PR was only about forwarding my initial reaction was "no". I'd start with a PR that adds value. Then the delegating methods will be OK, though I wouldn't use macros here. I'd use proper signatures and docs so users understand what arguments need to be passed.

In java there's a Path class which is somewhat similar to this, and I find myself using it a lot. being able to treat the path as a series of nodes seperated by the separator character is really quite handy. I found myself using methods like relativize a lot. I would highly recommending just calling this class Path though instead of Pathname.

I will personally about methods like #open and instead add overloads to existing File.open that accepts a Pathname instance instead.

That way, we avoid having to go over and update method signatures all over the place.

Thanks for the feedback. Ill address it. Currently this is more an example for a Path core class, not the initial Pathname class.

The idea behind this is to replace strings when handling files and directories for comfort, type safety and maybe security (e.g. injection protection). Following this idea, the path-related File and Dir functions whicn are then methods of Path can be removed in the future.

What do you think about this?

I'm not very fond of this implementation. I like moving path related methods from File to Path, it makes sense.

But, Path becomes required to join or expand paths (among others). I repeat myself, but it often just instantiates a class to throw it away immediately, to return a String. Same for some methods that are wrapping a single String into an Array, just to iterate over it and throw it away immediately. but this is bad for performance, since it requires to allocate HEAP memory that the GC will have to collect.

It also loses some null bytes check, which reopens some very important security holes. Please keep them until we are sure we can remove them (spoiler: we will most certainly keep them).

We can't expect a developer to have to instantiate a Path just to return the extname of a file (GC pressure), or to have to wrap a String into a Path so we can open a file. Treating paths as simple String still makes sense.

I would prefer a simpler solution that moves the File class methods verbatim to Path, so we'd have Path.join(*names) : String and Path.expand(path, dir = nil) : String methods, and so on. The Path instance methods could then take advantage of these. Then File and Dir methods would simply call to_s on paths it receives, accepting both a String (noop) or a Path, instead of wrapping the String into a Path, at least for the time being.

(sorry, wrong button)

We'll probably implement Path or Pathname in the future, as a struct, but this PR doesn't seem to be what we have in mind, so I'm closing this.