<div class="gmail_quote">On Wed, Jun 5, 2013 at 1:34 PM, Jonathan M Davis <span dir="ltr"><<a href="mailto:jmdavisProg@gmx.com" target="_blank">jmdavisProg@gmx.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Wednesday, June 05, 2013 22:19:21 Dylan Knutson wrote:<br>
> > I don't have a strong opinion regarding Path object vs. string<br>
> > functions, and I agree both have advantages and disadvantages.<br>
> > But I would be opposed to having both.<br>
><br>
> Personally, I'd prefer to just use the Path struct in std.path.<br>
> While a Path can be represented as a string, it's not the same<br>
> concept (the same way that a DateTime can be represented as an<br>
> integer, but we don't just pass times around as raw integer<br>
> types).<br>
<br>
</div>There's a significant difference between a type which has a value and units and<br>
one which is basically just a string or array of strings wrapped by another<br>
type. Not that a Path struct is without value, but I think that there's a very<br>
large difference in the amount of value that the two provide. AFAIK, very few<br>
bugs are caused by treating paths as strings, </blockquote><div><br></div><div>I disagree.</div><div><br></div><div>It allows to catch bugs early (eg: giving a $mypath environment variable to a binary, where the env variable wasn't set or set to an invalid path name). Constructing a Path object from it will immediately fail as opposed to later down the code with possibly evil artifacts (eg when using std.process.shell functions).</div>
<div><br></div><div>Other advantage : central location for all path object creations allows to instrument the code for example for logging all path names mentioned. Would be impossible with raw string type.</div><div><br>
</div><div>Other advantage: makes it easy to work with cross-platform code (ie operating on windows paths from posix), see my previous post in this thread.</div><div><br></div><div>I very much welcome this. There's a reason why other languages (C#, java) have such an abstraction. Given D's alias this functionality, this abstraction comes at 0 runtime cost and makes it work with 0 adaptation for most existing code. </div>
<div><br></div><div>What will it break? We should discuss that.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">but there are a lot of time-<br>

related bugs out there caused by using naked values instead of values with<br>
units.<br>
<div class="im"><br>
> This makes its integration into existing codebases/Phobos<br>
> literally as easy as<br>
</div>[snip]<br>
<br>
See, this is exactly the sort of thing I'm afraid of. I don't want to have to<br>
have arguments over whether a particular function should accept a path as a<br>
string or a struct. Right now, we have one way do to it, so it's clear, and it<br>
works just fine. If we add a Path struct, then we have two ways to do the same<br>
thing, and we're going to have a division among APIs as to which way to handle<br>
paths. And I think that we'll be very much worse of because of it. While there<br>
is value in having a path struct rather than a string, I don't think that it's<br>
worth the extra confusion and division that it'll cause. If we were going to<br>
have a path struct, we should have done that in the first place rather than<br>
using strings.<br>
<span class="HOEnZb"><font color="#888888"><br>
- Jonathan M Davis<br>
</font></span></blockquote></div><br>