Path as an object in std.path

Walter Bright newshound2 at digitalmars.com
Thu Jun 6 09:24:09 PDT 2013


On 6/6/2013 9:00 AM, Dylan Knutson wrote:
>> 1. Making a more 'palatable' interface is pretty much chasing rainbows. It
>> really isn't better, it is just different. In many ways, it is worse because
>> it cannot hope to duplicate the rich interface available for strings.
>
> .toString ?
>
>> 2. APIs that deal with filenames take strings and return strings, not Path
>> objects. Your code gets littered with path and filename components that are
>> sometimes Paths and sometimes strings and sometimes both.
>
> 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.


>> 3. Every time you deal with a filename or path, you have to decide whether to
>> use a Path or a string. This may seem like a small thing, but when writing a
>> lot of code to deal with paths, this becomes a fracking annoyance.
>
> 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.


> 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.


> 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.


> 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.


> 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.


> If the programmer is worried about the speed of the abstraction, deal with that
> separately.

Yes, he goes back to using strings.



More information about the Digitalmars-d mailing list