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@boostpro.com> wrote:
on Sun Jan 27 2013, Daniel Pfeifer <daniel-AT-pfeifer-mail.de> wrote:
2013/1/27 Dave Abrahams <dave@boostpro.com>:
on Sun Jan 27 2013, Rob Stewart <robertstewart-AT-comcast.net> wrote:
On Jan 25, 2013, at 6:52 PM, Dave Abrahams <dave@boostpro.com> 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