Path as an object in std.path

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Thu Jun 6 09:03:15 PDT 2013


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


More information about the Digitalmars-d mailing list