[phobos] next release (meaning of path)

[Steve Schveighoffer]

Would it be enough to have a function that takes a string (or inout(char)[] if 
possible) and returns a string[] with the path elements?  Also, a function to do 
the reverse.

I agree we need something to abstract as much as possible the path elements 
(separator, drive, extension, etc.), but the huge benefit of using a string for 
a path is that when a path struct exists, it's often used as the parameter type 
for paths.  This results in one having to wrap their paths in a Path struct just 
to call some function, even though they don't care about manipulating it.  I 
remember when using Tango, there were types to deal with all sorts of things 
(like files and paths) and I always had to use the docs when using them.  It was 
not very intuitive.

-Steve



----- Original Message ----
> From: Jonathan M Davis <jmdavisProg at gmx.com>
> To: phobos at puremagic.com
> Sent: Sun, January 2, 2011 7:25:08 PM
> Subject: Re: [phobos] next release (meaning of path)
> 
> On Sunday 02 January 2011 16:01:47 Andrei Alexandrescu wrote:
> > Let's have  a brief vote. Do you think we should have a string-like
> > structure Path  in std.path? What primitives should it have?
> > 
> > I'm fine using  strings, but I could be convinced to use a Path type if
> > it had some  compelling advantages.
> 
> I'm sure that it depends on the use case, but if  you're doing a lot of 
> operations on paths which would involve adding,  removing, or renaming 
> directories, then having a Path struct of some kind  which essentially held a 
> linked list of the pieces of the path could be  beneficial. If you're having to 
>
> constantly search for the Xth separator in  the string and the like - 
>especially 
>
> if you're then having to create a new  string with changes - it could be a bit 

> expensive to deal with just strings.  However, any time that you then need to 
> actually use the path - like opening  a file or whatnot - you'd need to 
> concatenate the whole thing together, and  doing that a lot could get expensive 
>
> too.
> 
> For the general use case, I  think that strings work just fine and that having 
>a 
>
> Path struct would be  unnecessary overhead. There are use cases where it could 
>be 
>
> useful, so it  might be useful to have a Path struct for such cases (what Boost 
>
> has is  rather nice from what I recall), but that isn't the typical case.
> 
> The one  really nice thing about using a Path struct that I can think of is 
>that 
>
> it  makes errors related to different separators less likely. The separator 
>would 
>
> generally be abstracted away in the user code and then dealt with  
>appropriately 
>
> by the Path struct when turned into string form for OS calls  and the like. It 

> might also help cases where you actually want to use the  separator in a file 
> name, though that's generally a bad idea, even if it can  be done.
> 
> I really liked Boost's path stuff last time I messed with it,  and having 
> something similar in Phobos would be cool, but I would worry that  that's just 

> overkill for the average case. Certainly, if we have a Path  struct of some 
>kind, 
>
> it needs to work with strings well and easily, or it's  going to be a problem.
> 
> Personally, I'm not sure how much I care either  way. A solid Path struct could 
>
> be very cool, but it also could be  overkill.
> 
> - Jonathan M  Davis
> _______________________________________________
> phobos mailing  list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>