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

From: David Abrahams (dave_at_[hidden])
Date: 2003-08-14 14:47:29

Beman Dawes <bdawes_at_[hidden]> writes:

> At 09:32 AM 8/12/2003, David Abrahams wrote:
>
>  >...
>  >> 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.
>  >...
>
> The generic path syntax was chosen to be a subset of the "Uniform
> Resource Identifiers (URI) : Generic Syntax", RFC-2396. Because that
> syntax is used in Internet URL's, it has become familiar to millions
> of people even if they never used POSIX or Windows.

Interesting choice.

> I'm not necessarily adverse to a different syntax. Several times
> during development something better was almost within reach, but I
> never could quite carry it off.
>
> If you would like to write up a grammar and rules as a more formal
> proposal, we can all take a look and judge how it would perform in the
> cases we think are important.

I don't think I believe in a path object which always has to be
representable portably (or even semi-portably as we have now), so I
don't think I'm going to do that.  I think I'd like to see native path
manipulators with pluggable portability checking and bidirectional
portable path format conversion.  In a system like that, the existing
format may be just fine.  However, I would refuse to convert /foo to a
portable format on windows, throwing an exception instead.

>  >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.
>
> You have conflict with existing practice for one group or another. If
> all paths which begin with '/' are complete, that conflicts with the
> experience of Windows programmers. If they aren't, that conflicts with
> the experience of POSIX programmers.

The entanglement with "portable representation" is confusing this
discussion I think.  Paths don't "begin with '/'".  They "have (or do
not have) a portable representation which begins with '/'".  They also
have (or do not have) a native representation which begins with '/'.
These are not neccessarily the same thing.  People should look to the
native representation to meet their platform-specific expectations.

>  >    2. The rules for understanding generic path syntax are greatly
>  >       simplified and can be understood without platform-specific
>  >       knowledge.
>
> I'm probably misunderstanding your proposal because it sounds like you
> are introducing special rules for the first non-'/' element. A formal
> proposal would clarify that.

No, I only reluctantly made a suggestion for representing truly
non-portable paths, but it is not part of my proposal.  Either a path
is portable or not and we shouldn't pretend non-portable paths have a
portable representation.

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