At 11:01 PM 8/21/2003, David Abrahams wrote: >Beman Dawes <[EMAIL PROTECTED]> writes: > >> At 04:49 PM 8/21/2003, David Abrahams wrote: >> > >> >This name, too, seems sorta redundant. Seriously, my mind forgets >> >the "file_" in the middle every time I use it and I've had a bunch of >> >stupid compiler errors because of it. Is there any reason >> >"native_file_string" is superior to "native_string"? >> >> To clearly distinguish between "native_file_string()" and >> "native_directory_string()". > >Grrr. OpenVMS certainly throws a wrench in this model, doesn't it?
No, VMS and OpenVMS were among the specific cases used to develop the design, and the whole point of having two functions is to accomodate the two different formats such file systems employ. Down at the level of calls to the native API, the implementation always knows which to call, by the way.
>Should we give paths knowledge of whether they refer to files or >directories, and construct them with functions like file_path() and >directory_path(), so that there can be a single way to "go native"?
Two flavors of that design approach were investigated in depth, to the point of producing a partially working implementation for one and a fully working implementation of the other. They were abandoned because they turned out to be more complicated that expected, and the practical benefits were slim.
One was based on a generic grammar that distinguished between directories and files, and the other used classes directory_path and file_path derived from path, IIRC.
>I can think of only one context in which I don't know whether I'm >working with a file or directory: when iterating over the contents of >a directory. In that context I'll almost certainly want to know >whether I've got a file or directory pretty soon anyway.
While that is often the case, some user or library functions (like exists()) find it convenient to take a path that can be either a directory or a file path. It gets messy. Conversions were a problem, even though they were only needed occasionally. I ended up becoming much more of a fan of the UNIX "a path is a path, doesn't matter to which" approach, both at the grammar and interface levels.
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
