>... >> 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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
