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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-08-12 07:08:02

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? Can it handle server and share names?

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

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.

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

--Beman