Path as an object in std.path

[Regan Heath]

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

> On Wed, 05 Jun 2013 14:26:39 +0100, Andrei Alexandrescu  
> <SeeWebsiteForEmail at 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/