Path as an object in std.path

[Dylan Knutson]

On Thursday, 6 June 2013 at 16:24:11 UTC, Walter Bright wrote:
>> As for APIs that return strings, a `Path toPath(string)` 
>> function could be added
>> in std.path? Another solution would be to migrate the parts of 
>> Phobos that use
>> path strings to using actual paths. They could be overloaded 
>> with a counterpart
>> that also takes a string, but the toPath function would be 
>> pretty useful here.
>
> Yes, your code becomes littered with conversions. Ugh.

As opposed to the rest of the conventions that Phobos uses?

>>
>> If there should only be one API used, I'd suggest just use 
>> Path.
>
> Except that just doesn't work out in practice. An awful lot 
> uses strings, and again, people want to use the incredibly rich 
> string manipulation code out there on paths.

Hence subtyping.

>
>> the more I realize how little
>> code would break, and how easy it'd be to fix that.
>
> That's been used to justify every code breakage. And yet, 
> people eschew using D because of constant code breakage. It 
> must stop.

Well, it comes down to are we willing to marginally break code 
for the sake of a better API. D and Phobos aren't considered 
stable by any standard; I don't think we should treat them like 
they're set in stone. Also, deprecation gives developers plenty 
of time to update their code (if they have to at all).

>
>> It even takes less chars :-P and it only allocates on Path == 
>> Path and Path ==
>> string comparison. Which would have been done manually anyways.
>
> Doing memory allocation to do == is a bad idea. People 
> intuitively think of == as a cheap operation.

It only allocates if buildNormalPath allocates. And if you aren't 
using buildNormalPath in the first place before comparing 
strings, you're comparing paths wrong.

>> Well, that's not so much a limitation of Path or path 
>> functions as much as it is
>> with the operating systems themselves. You still run into that 
>> with strings. I'm
>> not trying to do anything groundbreaking, just abstract away 
>> the concept of a
>> path so it's easy to write larger applications.
>
> But it isn't easier to use a Path object. That's one of the 
> things I discovered when using them - it's never easier.

Projects such as Dub, Vibe, and to an extent Tango disagree.

>> Good practice says don't worry about the implementation of 
>> what you can't see.
>
> Yeah, well, you said that == allocates memory under the hood, 
> which is surprising behavior. Real programs definitely worry 
> about the implementation.

Well, they shouldn't. Profile code first, see where the hotspots 
are, and fix those. I'd be very surprised if path comparison and 
manipulation is so heavily used, it becomes a slow spot for 
programs. And if it does, that's not the fault of the Path struct 
itself, but rather of the underlying functions it uses.

>
>> If the programmer is worried about the speed of the 
>> abstraction, deal with that
>> separately.
>
> Yes, he goes back to using strings.

See above; I can't think of any use case for paths where they 
account for a considerable amount of run time.