Beman Dawes <[EMAIL PROTECTED]> 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
