Path as an object in std.path

[Timothee Cour]

On Wed, Jun 5, 2013 at 1:34 PM, Jonathan M Davis <jmdavisProg at gmx.com>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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130605/b299e4b4/attachment-0001.html>