On 6/6/13 11:36 AM, Walter Bright wrote:
To repeat the objections:
Now with devil's advocate interjections:
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.
Subtyping (Path is a subtype of string by means of alias this) should
make getting from paths to strings easy, and getting back from strings
to paths one constructor call away (which adds correctness).
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.
Subtyping should make it easy to pass paths to APIs that expect strings.
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.
If there's a reward for using paths the annoyance factor may be reduced.
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.
Subtyping should take care of this.
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.
Subtyping makes one way easy and constructors make the other way
affordable. Again, this comes back to perceived gains that compensate
for the shortcomings.
6. If you try not to do (5), you break all existing code.
Only "half".
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.
Lazy canonicalization may help.
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
That is actually an argument in favor of good encapsulation, not against.
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'm not sure whether the generalization holds.
Andrei
