Re: [boost] Re: [filesystem] native_file_string

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-08-22 14:39:09

At 11:01 PM 8/21/2003, David Abrahams wrote:
 >Beman Dawes <bdawes_at_[hidden]> 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