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.
> 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
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk