Path as an object in std.path

Regan Heath regan at netmail.co.nz
Fri Jun 7 07:35:13 PDT 2013


On Thu, 06 Jun 2013 15:54:24 +0100, Dylan Knutson <tcdknutson at gmail.com>  
wrote:

> On Thursday, 6 June 2013 at 10:48:54 UTC, Lars T. Kyllingstad wrote:
>> On Thursday, 6 June 2013 at 10:32:36 UTC, Regan Heath wrote:
>>> On Thu, 06 Jun 2013 08:55:50 +0100, Lars T. Kyllingstad  
>>> <public at kyllingen.net> wrote:
>>>
>>>> On Thursday, 6 June 2013 at 07:05:52 UTC, Lars T. Kyllingstad wrote:
>>>>>
>>>>> [...]
>>>>
>>>> Let me add some more to this.  To justify the addition of such a  
>>>> type, it needs to pull its own weight.  For added value, it could do  
>>>> one or both of the following:
>>>
>>> Does System.IO.DirectoryInfo:
>>> http://msdn.microsoft.com/en-us/library/system.io.directoryinfo.aspx
>>>
>>> Add sufficient value to justify it's existence to your mind?
>>>
>>> vs just having System.IO.Directory:
>>> http://msdn.microsoft.com/en-us/library/system.io.directory.aspx
>>
>> They add great value, but that is a completely different discussion, as  
>> these are more similar to std.file.DirEntry.  The added value is mainly  
>> in the performance benefits; for example,
>>
>>     if (exists(f) && isFile(f) && timeLastModified(f) < d) ...
>>
>> requires three filesystem lookups (stat() calls), whereas
>>
>>     auto de = dirEntry(f);
>>     if (de.exists && de.isFile && de.timeLastModified < d) ...
>>
>> is just one.
>>
>> I see no such benefit in the proposed Path type.
>
> Path and dirEntry are different modules with different goals to fulfill.  
> I don't think it's appropriate to compare a module whose function is  
> path manipulation with one whose is querying filesystem information.

Yeah, my fault.  I didn't take the time to look at the proposed module in  
detail.

R

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


More information about the Digitalmars-d mailing list