On Thursday, 6 June 2013 at 15:24:09 UTC, Lars T. Kyllingstad
wrote:
On Thursday, 6 June 2013 at 14:39:03 UTC, Dylan Knutson wrote:
[...]
I don't think that there'll be any performance improvements by
making in place modification functions. Considering under the
hood the path object is just a string, and that string's
reference needs to be changed with each modification, I don't
see how manipulation can be made faster.
Why does _path have to be an immutable string? It could just
as well be a char[], or it could be templated on the character
type.
[...]
The more I think about it, the more partial I am to removing
the existing string methods in std.path. At most, using a Path
object increases number of characters typed by 6 (`Path()`).
And even then, chances are you'll be saving characters as
method names can be simplified to remove `path` from them:
buildNormalizedPath -> normalized, isValidPath -> isValid,
etc. Even with user code breaking, 1) D isn't exactly
considered a stable language quite yet; I'm sure that users
expect code breakage with each new release, and 2) it's
trivial to convert code that uses the string based API to the
object based API.
I know D isn't 100% stable yet, but bear in mind that this
module was introduced no more than two years ago, as part of
the (still-ongoing) effort to revamp the old modules from the
D1 days. It was accepted with a unanimous vote after a
comprehensive review by the D community. And already you want
another breaking redesign? I am strongly opposed to this.
Well, keep in mind that D 2 years ago was a different beast.
AFAIK, D only recently got `alias X this`, which solves 90% of
breakage problems when passing around Paths.
FWIW, having Path be an object adds consistency with the rest of
Phobos, which has many entities which could be expressed as
primitives, expressed as objects. To name a few, DateTime is an
object, File is an object, and DirEntry is an object. Yes, they
could be described as integers, or a pointer, or a string, but
it's less cognitive load on the developer to recognize them as
separate types.
