Path as an object in std.path

Lars T. Kyllingstad public at kyllingen.net
Thu Jun 6 00:05:51 PDT 2013


On Wednesday, 5 June 2013 at 06:27:46 UTC, Dylan Knutson wrote:
> Hello,
> 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".

Since I am the designer and primary author of std.path, I should 
probably say something.

When I first started working on "the new std.path" a couple of 
years ago, I initially entertained the idea of writing it in 
terms of a dedicated Path type.  I was quickly convinced 
otherwise by others, and proceeded to design the module around 
normal strings.

For the last two years I've been working more in C++ than in D 
(by necessity, not by desire), and for all my path-manipulation 
needs I've been using boost::filesystem.  This library has a 
dedicated path type, so I've gained some experience with this 
kind of API.  And I am *really* happy we went with the string 
solution for std.path.

Paths are usually obtained in string form, and they are normally 
passed to other functions and third party libraries in string 
form.  Having to convert them to something else just to do what 
is, in fact, string manipulations, is just annoying.

(One of my biggest gripes with boost::filesystem is that 
conversions between path and string necessitate a copy, which is 
not a problem with your Path type, so in that respect it is 
better than Boost's solution.)


> [...]
>
> Why I think it should be reconsidered for inclusion in the std 
> (listed in the pull):
> * Adds a (more) platform independent abstraction for path 
> strings.

How is this more platform independent?  It is just a simple 
wrapper around a string, with methods that forward to 
already-extant module-level functions.


> * Path provides a type safe way to pass, compare, and 
> manipulate arbitrary path strings.

How is it safer?  I would agree with this if it verified that 
isValidpath(_path) on construction and maintained this as an 
invariant, but I cannot see that it does.


> * It wraps over the functions defined in std.path, so behavior 
> of methods on Path are, in most cases, identical to their 
> corresponding module function.

Then what is the added value?

Having Path together with normal string functions in the same 
module will be confusing (there are two almost-equal ways of 
doing the same thing; which one should I choose?), and it will 
add code duplication (now my code has to accept paths both as 
strings and as Paths).

As the author of std.path this may come across as hostile or 
jealous, but I don't see that the proposed change improves 
anything.

Lars


More information about the Digitalmars-d mailing list