Path as an object in std.path
Dylan Knutson
tcdknutson at gmail.com
Wed Jun 5 13:52:23 PDT 2013
> 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.
Dub is forced to define its own separate Path type because, as
its author states, using a string to represent a path "more often
than not results in hidden bugs."
(https://github.com/rejectedsoftware/dub/issues/79). Representing
a path is just fine in a small script, but the moment you've got
to handle stuff like path comparison, building, and general
manipulation, you're better off defining an abstraction for it.
> 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.
I see no problem with just keeping Phobos as it is, it was just a
suggestion to make use of new functionality. A function that
takes a string can accept a Path *or* a string, and it'll work
just fine, thanks to subtyping.
void bar(Path path) { return; }
void foo(string str) { return; }
Path p = `baz\quixx`;
bar(p);
foo(p);
So there doesn't have to be an argument over what a function
should accept; that's up to the function's internal
implementation. From the outside, it'll accept both.
More information about the Digitalmars-d
mailing list