Path as an object in std.path

John Colvin john.loughran.colvin at gmail.com
Wed Jun 5 07:10:22 PDT 2013


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.


More information about the Digitalmars-d mailing list