Hello,
I'd like to open up the idea of Path being an object in std.path. I've submitted a pull (https://github.com/D-Programming-Language/phobos/pull/1333) that adds a Path struct to std.path, "which exposes a much more palatable interface to path string manipulation".

As jmdavis points out, this has previously been discussed. However, I can't find that discussion, and I think that the benefits of including an OO way to deal with paths is a serious gain for the standard library.

Why I think it should be reconsidered for inclusion in the std (listed in the pull):
* Adds a (more) platform independent abstraction for path strings.
* Path provides a type safe way to pass, compare, and manipulate arbitrary path strings.
* It wraps over the functions defined in std.path, so behavior of methods on Path are, in most cases, identical to their corresponding module function.

I'd like some feedback on what others think about this; I'd hate to see this commit closed due to a discussion that happened at a different point in D's development when the language had different needs.

Thank you.

On Wednesday, 5 June 2013 at 06:27:46 UTC, Dylan Knutson wrote:
> "which exposes a much more palatable interface to path string manipulation".
> [...snip...]
> I'd like some feedback on what others think about this;

personally, I prefer the current implementation and found it easy to use for the multitudes of tiny scripts I've written.  I wouldn't like to create an "object" just to call isAbsolute.

That being said, I don't see why having the struct would hurt.

Nice work by the way

On 2013-06-05 09:11, Joshua Niehus wrote:

> personally, I prefer the current implementation and found it easy to use
> for the multitudes of tiny scripts I've written.  I wouldn't like to
> create an "object" just to call isAbsolute.

I agree. But if you're passing around a lot of paths it would probably be a good idea to have a proper type for the paths.

> That being said, I don't see why having the struct would hurt.



-- 
/Jacob Carlborg

On Wednesday, 5 June 2013 at 07:11:49 UTC, Joshua Niehus wrote:
> On Wednesday, 5 June 2013 at 06:27:46 UTC, Dylan Knutson wrote:
>> "which exposes a much more palatable interface to path string manipulation".
>> [...snip...]
>> I'd like some feedback on what others think about this;
>
> personally, I prefer the current implementation and found it easy to use for the multitudes of tiny scripts I've written.  I wouldn't like to create an "object" just to call isAbsolute.
>
> That being said, I don't see why having the struct would hurt.
>
> Nice work by the way

Is there any reason why we couldn't keep the string-based free functions around as well?

On 6/5/13 2:27 AM, Dylan Knutson wrote:
> Hello,
> I'd like to open up the idea of Path being an object in std.path. I've
> submitted a pull
> (https://github.com/D-Programming-Language/phobos/pull/1333) that adds a
> Path struct to std.path, "which exposes a much more palatable interface
> to path string manipulation".
[snip]

Great, thanks for this work. I agree that the proposal deserves a fair shake.

Andrei

On 6/5/13 7:33 AM, John Colvin wrote:
> On Wednesday, 5 June 2013 at 07:11:49 UTC, Joshua Niehus wrote:
>> On Wednesday, 5 June 2013 at 06:27:46 UTC, Dylan Knutson wrote:
>>> "which exposes a much more palatable interface to path string
>>> manipulation".
>>> [...snip...]
>>> I'd like some feedback on what others think about this;
>>
>> personally, I prefer the current implementation and found it easy to
>> use for the multitudes of tiny scripts I've written. I wouldn't like
>> to create an "object" just to call isAbsolute.
>>
>> That being said, I don't see why having the struct would hurt.
>>
>> Nice work by the way
>
> Is there any reason why we couldn't keep the string-based free functions
> around as well?

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.

Andrei

On Wednesday, 5 June 2013 at 13:26:39 UTC, Andrei Alexandrescu wrote:
> On 6/5/13 7:33 AM, John Colvin wrote:
>> On Wednesday, 5 June 2013 at 07:11:49 UTC, Joshua Niehus wrote:
>>> On Wednesday, 5 June 2013 at 06:27:46 UTC, Dylan Knutson wrote:
>>>> "which exposes a much more palatable interface to path string
>>>> manipulation".
>>>> [...snip...]
>>>> I'd like some feedback on what others think about this;
>>>
>>> personally, I prefer the current implementation and found it easy to
>>> use for the multitudes of tiny scripts I've written. I wouldn't like
>>> to create an "object" just to call isAbsolute.
>>>
>>> That being said, I don't see why having the struct would hurt.
>>>
>>> Nice work by the way
>>
>> Is there any reason why we couldn't keep the string-based free functions
>> around as well?
>
> 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.
>
> Andrei

Because of duplication of implementation? Or is it simply "2 ways to do the same thing" is bad?


I was imagining the following situation:

    Free functions, similar/identical to current

    Struct that provides all current functionality by wrapping the free functions, plus any extra stuff that is only appropriate for a path object.


Unfortunately the current naming scheme doesn't really suit this idea that well.

On Wed, 05 Jun 2013 14:26:39 +0100, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 6/5/13 7:33 AM, John Colvin wrote:
>> On Wednesday, 5 June 2013 at 07:11:49 UTC, Joshua Niehus wrote:
>>> On Wednesday, 5 June 2013 at 06:27:46 UTC, Dylan Knutson wrote:
>>>> "which exposes a much more palatable interface to path string
>>>> manipulation".
>>>> [...snip...]
>>>> I'd like some feedback on what others think about this;
>>>
>>> personally, I prefer the current implementation and found it easy to
>>> use for the multitudes of tiny scripts I've written. I wouldn't like
>>> to create an "object" just to call isAbsolute.
>>>
>>> That being said, I don't see why having the struct would hurt.
>>>
>>> Nice work by the way
>>
>> Is there any reason why we couldn't keep the string-based free functions
>> around as well?
>
> 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.

C# has both:
1. System.IO.FileInfo and System.IO.DirectoryInfo non-static/instance classes with methods i.e. Delete()
2. System.File and System.Directory static classes with methods accepting strings i.e. Delete(string name)

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Wed, 05 Jun 2013 15:12:22 +0100, Regan Heath <regan@netmail.co.nz> wrote:

> On Wed, 05 Jun 2013 14:26:39 +0100, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On 6/5/13 7:33 AM, John Colvin wrote:
>>> On Wednesday, 5 June 2013 at 07:11:49 UTC, Joshua Niehus wrote:
>>>> On Wednesday, 5 June 2013 at 06:27:46 UTC, Dylan Knutson wrote:
>>>>> "which exposes a much more palatable interface to path string
>>>>> manipulation".
>>>>> [...snip...]
>>>>> I'd like some feedback on what others think about this;
>>>>
>>>> personally, I prefer the current implementation and found it easy to
>>>> use for the multitudes of tiny scripts I've written. I wouldn't like
>>>> to create an "object" just to call isAbsolute.
>>>>
>>>> That being said, I don't see why having the struct would hurt.
>>>>
>>>> Nice work by the way
>>>
>>> Is there any reason why we couldn't keep the string-based free functions
>>> around as well?
>>
>> 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.
>
> C# has both:
> 1. System.IO.FileInfo and System.IO.DirectoryInfo non-static/instance classes with methods i.e. Delete()
> 2. System.File and System.Directory static classes with methods accepting strings i.e. Delete(string name)

I forgot to say.. I've used both in different situations.  Sometimes you get a FileInfo/DirectoryInfo from another method, or you have created one because you're going to re-use the path/information a lot (to get file attributes etc) and sometimes you just need to build a path using Path.Combine (into a string) and delete it, or similar.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

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

However, I can't imagine that'd be feasible as it'd break a lot of code. My suggestion would be to just keep the freestanding functions to operate on raw strings, and then migrate over code that depends on std.path to use the Path struct as needed. I realize that this is easier said than done, but even then it shouldn't be a lot of work as Path can implicitly be converted to a string.

This makes its integration into existing codebases/Phobos literally as easy as using "Path my_path = `foo\bar`" instead of "string my_path = `foo\bar`". You lose no functionality but gain type safety if you have to do any future refactoring.

>  I wouldn't like to create an "object" just to call isAbsolute.

Agreed. The best course of action would probably be keep the raw functions as they exist (think of them as the static versions of Path methods). However, for large applications, the type safety of a Path object makes working with paths much easier.