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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-08-14 13:52:44

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.

 >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.

 >    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.

 >    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).

That isn't a problem in practice. The most portable and usually best way to 
deal with path completion is the same as with other libraries and 
programming languages. The bulk of the program code should always deal only 
in terms of relative paths. At some point (based on user input, an 
initial_path() default, or the operating system's path completion algorithm 
when the platform API is called with relative path arguments), the relative 
paths are completed to become the paths actually used in some platform API 
operation.

Perhaps I should explain that and give some examples in the docs. Perhaps 
the point needs to be made more strongly that the Filesystem library isn't 
doing any hidden completion manipulation of paths; in the end the native 
string just gets passed on to the operating system as is done by all other 
I/O libraries I'm aware of.

--Beman