On Wed, Jun 5, 2013 at 1:34 PM, Jonathan M Davis <[email protected]>wrote:
> 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, I disagree. 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). 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. 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. 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. What will it break? We should discuss that. > 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 >
