Path as an object in std.path
Jonathan M Davis
jmdavisProg at gmx.com
Wed Jun 5 13:34:27 PDT 2013
On Wednesday, June 05, 2013 22:19:21 Dylan Knutson wrote:
> > I don't have a strong opinion regarding Path object vs. string
> > functions, and I agree both have advantages and disadvantages.
> > But I would be opposed to having both.
>
> Personally, I'd prefer to just use the Path struct in std.path.
> While a Path can be represented as a string, it's not the same
> concept (the same way that a DateTime can be represented as an
> integer, but we don't just pass times around as raw integer
> types).
There's a significant difference between a type which has a value and units and
one which is basically just a string or array of strings wrapped by another
type. Not that a Path struct is without value, but I think that there's a very
large difference in the amount of value that the two provide. AFAIK, very few
bugs are caused by treating paths as strings, but there are a lot of time-
related bugs out there caused by using naked values instead of values with
units.
> This makes its integration into existing codebases/Phobos
> literally as easy as
[snip]
See, this is exactly the sort of thing I'm afraid of. I don't want to have to
have arguments over whether a particular function should accept a path as a
string or a struct. Right now, we have one way do to it, so it's clear, and it
works just fine. If we add a Path struct, then we have two ways to do the same
thing, and we're going to have a division among APIs as to which way to handle
paths. And I think that we'll be very much worse of because of it. While there
is value in having a path struct rather than a string, I don't think that it's
worth the extra confusion and division that it'll cause. If we were going to
have a path struct, we should have done that in the first place rather than
using strings.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list