Path as an object in std.path
Dylan Knutson
tcdknutson at gmail.com
Thu Jun 6 07:39:02 PDT 2013
> Let me add some more to this. To justify the addition of such
> a type, it needs to pull its own weight. For added value, it
> could do one or both of the following:
>
> 1. Maintain an isValidPath() invariant, for early error
> detection. (On POSIX, this is rather trivial, as any string
> that does not contain a null character is in principle a valid
> path, but on Windows, the situation is different.)
That's a possibility.
> 2. Add in-place versions of path modifiers (setExtension,
> setDrive, etc.), for improved performance.
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.
> One solution would be for Path to be a trivial string wrapper
> which does (1) and not (2). In this case, it is justified to
> have Path *in addition to* the existing functions.
>
> Another solution would be for Path to do (2), possibly in
> addition to (1). However, in this case it should be a
> *replacement* for the existing functions, and not an addition.
> Otherwise, we have two almost-equal ways of doing the same
> thing, which should be avoided. (I am not advocating this,
> however, as it will massively break user code all over again.)
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.
More information about the Digitalmars-d
mailing list