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 <[email protected]> > To: [email protected] > 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 > [email protected] > http://lists.puremagic.com/mailman/listinfo/phobos > _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
