[boost] Re: Boost.Filesystem: naming, canonical path

From: David Abrahams (dave_at_[hidden])
Date: 2003-08-12 08:32:32

Beman Dawes <bdawes_at_[hidden]> writes:

> At 12:31 PM 8/11/2003, David Abrahams wrote:
>
>  >Beman Dawes <bdawes_at_[hidden]> writes:
>  >
>  >> At 07:39 PM 8/10/2003, David Abrahams wrote:
>  >
>  >>  >If I were king, the portable, generic version of windows-native
>  >>  >"c:/foo" would be "/c/foo" and the portable generic version of
>  >>  >windows-native "/foo" would be *current_path().begin()/"foo".  Is
>  >>  >there a reason that approach was rejected?
>  >>
>  >> Yes, it had five or six different problems IIRC, although some of
>  >> them can be fixed by adding additional syntax. For example, the
>  >> ambiguity in "/c/foo" - is it a relative path starting with a
>  >> directory named "c" or a complete path to the c drive
>  >
>  >Read as a generic path according to my system, it is not a relative
>  >path because it starts with a slash.  That's simple and there should
>  >be no confusion assuming you know you're not looking at a native format..
>
> Can that scheme represent paths which are relative to the root
> directory of an unspecified drive? Relative to the current directory
> of a specified drive? 

No, those are not portable concepts so in my world there's no need for
a portable representation for them.

However, as you said, those things could be handled with syntax
extensions if you really wanted:

relative to the root of an unspecified drive:
     .../foo/bar

relative to the current directory of the C drive:
     /C/.../foo/bar

> Can it handle server and share names?

Sure, just the way you do now:

      //foo/bar/whatever

> And most important, can it do so in a way that is obvious to a human
> reader or writer?

This part may be asking too much.  What's obvious to a human reader or
writer is going to be what she's familiar with on the platform she
uses.  The expectations of Windows and Unix users clash, as you've
seen.

> Schemes which don't supply obvious syntactic markers such as ":" or
> "//" for special names are very hard for a human reader or writer to
> parse correctly.

I wonder whether it's a good idea to expect the human reader to be
able to parse "portable generic" path representations correctly.  We
have native representations for presenting portable generic paths to
users.  I almost think it's a mistake to provide a "portable generic"
string conversion (though I think I understand the practical reasons
for it).

There's no reason you can't just keep the trailing colon as part of
the first path element if you think it's clearer (**):

    Windows          Generic
    c:/foo/bar       /c:/foo/bar
    /foo/bar         .../foo/bar
    c:foo/bar        /c:/.../foo/bar

It's pretty easy to handle this without having to invent a new term
for or to give up a simple way of understanding "absolute path".

(**) But it might not be a good idea because you'll want to throw out
the colon when translating to native paths on non-windows systems.

> Once syntactic markers and/or rules are introduced, whether to
> eliminate ambiguities or to improve readability and writablity, the
> question is then what are the advantages of a new and unfamiliar set
> of markers and/or rules? 

You're already making paths unfamiliar by "genericizing" them.  It
would be unfair to VMS and whatever other OSes will be supported to
say otherwise just because you are only changing slash direction on
windows paths.

The advantages are:

    1. You can use familiar terminology - there should be no need to
       throw out the term "absolute" just to meet the expectations of
       Unix programmers who expect all paths beginning with '/' to be
       absolute.

    2. The rules for understanding generic path syntax are greatly
       simplified and can be understood without platform-specific
       knowledge.

    3. Portable/generic paths can actually be portable/generic, as
       advertised.  You won't have the problem we have now: no
       complete path that works on a Windows machine can also work on
       a Unix machine (disregarding paths to remote machines, of
       course).

> The existing operating system syntax and rules are familiar to a
> large number of programmers. Even programmers who don't ever work
> with multi-rooted file systems often have a passing familiarity with
> the Windows rules, which are particularly important as it is the
> most widely used multi-rooted system.
>
> In other words, it isn't enough for some competing scheme to
> work. It has to have enough advantages to make it worthwhile for
> programmers to learn any new syntax or rules.

They have to learn new syntax and rules anyway.  Why not keep them
simple and coherent?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com