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
