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