Path as an object in std.path

[Walter Bright]

On 6/4/2013 11:27 PM, Dylan Knutson wrote:
> I'd like to open up the idea of Path being an object in std.path. I've submitted
> a pull (https://github.com/D-Programming-Language/phobos/pull/1333) that adds a
> Path struct to std.path, "which exposes a much more palatable interface to path
> string manipulation".


I've succumbed to the temptation to do this several times over the years.

I always wind up backing it out and going back to strings.

The objections have all been already mentioned by others in this thread. I 
understand the motivation for doing it, it seems like a great idea, but I am 
strongly opposed to it.

To repeat the objections:

1. Making a more 'palatable' interface is pretty much chasing rainbows. It 
really isn't better, it is just different. In many ways, it is worse because it 
cannot hope to duplicate the rich interface available for strings.

2. APIs that deal with filenames take strings and return strings, not Path 
objects. Your code gets littered with path and filename components that are 
sometimes Paths and sometimes strings and sometimes both.

3. Every time you deal with a filename or path, you have to decide whether to 
use a Path or a string. This may seem like a small thing, but when writing a lot 
of code to deal with paths, this becomes a fracking annoyance.

4. An awful lot of path manipulation is done using string functions. Ever do 
regexes on paths? I do. But regex deals with strings, not Path objects. Ditto 
for the rest of the universe of code that deals with strings.

5. You wind up with two parallel universes of functions to deal with paths - one 
dealing with strings, one with Paths, oh, and a third universe of crap that 
deals with mixed strings and Paths.

6. If you try not to do (5), you break all existing code.

7. People like writing paths as "/etc/hosts", not Path("/etc/hosts"). People 
will not stand for a Path constructor that winds up allocating memory so it can 
rewrite the string in a canonical path representation.

8. There really isn't any such thing as a portable path representation. It's 
more than just \ vs /. There are the drive prefixes in Windows that have no 
analog in Linux. Sometimes case matters in Linux, where it would be ignored 
under Windows. There are 8.3 issues sometimes. The only thing you can do is come 
up with a subset of what works across systems, and then of course you have to go 
back to using strings when you need to access D:\foo\abc.c

9. People think about paths in terms of strings, not Path objects. Adding an 
abstraction layer always produces the feeling of "what is it doing, is it 
allocating memory, is it slow, is it doing something clever that I don't 
need/want?". This is cognitive baggage, and interferes with writing clear, 
correct code.


I've written a lot of cross-platform path code, I've tried the Path object thing 
multiple times, and I wrote the original std.path, and it uses strings because 
of my experience.