Re: [boost] boost::filesystem::path frustration

Subject: Re: [boost] boost::filesystem::path frustration
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-01-29 11:50:49

on Mon Jan 28 2013, Ryo IGARASHI <rigarash-AT-gmail.com> wrote:

> Hi,
>
> On Mon, Jan 28, 2013 at 9:55 AM, Dave Abrahams <dave_at_[hidden]> wrote:
>>
>> on Sun Jan 27 2013, Daniel Pfeifer <daniel-AT-pfeifer-mail.de> wrote:
>>
>>> 2013/1/27 Dave Abrahams <dave_at_[hidden]>:
>>>>
>>>> on Sun Jan 27 2013, Rob Stewart <robertstewart-AT-comcast.net> wrote:
>>>>
>>>>> On Jan 25, 2013, at 6:52 PM, Dave Abrahams <dave_at_[hidden]> wrote:
>>>>>
>>>
>>>>>> IMO paths are abstract entities that aren't necessarily realized in
>>>>>> the local filesystem.  The results of pure path manipulations must
>>>>>> therefore not depend on the state of the local filesystem.
>>>>>> Operations accepting paths as input that depend on the local
>>>>>> filesystem structure should be seen as operations on the filesystem
>>>>>> rather than operations on paths.
>>>>>
>>>>> +1
>>>>>
>>>>> I also like the idea that a path is a container of elements.
>>>>
>>>> In fact there probably ought to be an object representing the local
>>>> filesystem, so you could also (in principle) do operations on a remote
>>>> filesystem.
>>>
>>> ... or a virtual filesystem (eg. an archive).
>>
>> +1
>
> If handling virtual or remote file systems is needed,
> isn't it better to generalize 'path' to handle URIs[1]?

-1. In that case you have to build knowledge about every filesystem-y
 thing into "path."  That's an awful lot of coupling and inflexibility.
If you want to handle URIs, there should be a uri_filesystem type that
has an extensible set of handlers (other filesystem objects) that can be
plugged in.  But you shouldn't have to use that, which requires dynamic
dispatching, just to traverse a known filesystem.

-- 
Dave Abrahams
BoostPro Computing                  Software Development        Training
http://www.boostpro.com             Clang/LLVM/EDG Compilers  C++  Boost