RE: [boost] Filesystem attributes

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-03-03 17:03:35

At 12:29 PM 3/3/2002, Jeff Garland wrote:

 >> iterator into an iterator matching the standard requirements for
 >> iterators and the filenames seems to be an obvious choice for this: A
 >> basic goal was to make simple things simple and filling a container 
with
 >> the names in a container using
 >>
 >>    std::vector<std::string> dir((dir_it("dir2")), dir_it());
 >>
 >> seems to be easy enough (note, BTW, that your approach makes even 
things
 >> like this much harder!).
 >
 >What's wrong with:
 >
 >     std::vector<std::directory_entry> dir((dir_it("dir2")), dir_it());
 >
 >I don't see why this is harder...

I'm with Jeff; I don't see the problem.  In fact his code above is one of 
my test cases.

 >Well sometimes the client will want the full path and sometimes not.  The
 >earlier discussion was that the client needs a way to manipulate these
 >without having to write non-portable path manipulation code.

Yes, and also without having to explicitly call composition or 
decomposition functions.

 >> The whole property map issue is to avoid special handling of 
attributes.
 >
 >I'm not generally in disagreement with the property map approach...

And I'm not either, particularly for most of the attributes, which may vary 
from system to system.

But there are a few basic attributes (name, directory path, full path and 
is_directory) which IMO should be required, and should be accessible with 
very straightforward syntax.  Otherwise people will make mistakes, write 
non-portable code, and it will get messy.

 >Again, I don't see how it is going to be 'opaque'.  There is going to be
 >some type returned by operator*.  I presume what you are saying is the 
only
 >useful thing a client can do is to send this into the property maps to 
get
 >attributes.
 >
 >And at the end of the story I'm fine with the full blown property 
approach.
 >It's not my preferred interface approach in general b/c I believe the
 >design is more obscure and outside convention for new users.  But I
 >understand the motivations, and no matter, b/c this can easily be 
adapted.
 >However to be consistent it clearly says to me that operator* should not
 >return std::string, but must return dir_entry.  It's just that dir_entry
 >provides no public methods....

I assume you mean no public methods beyond those required for use in 
standard containers.

But that sounds awfully dogmatic.  What possible harm comes from making a 
small number of functions public?

This seems like the wrong library to use as a vehicle to try to convince 
people to use only the new property map idiom.  Why not use the old member 
function idiom for the common uses (names, is_directory), and leave the new 
idiom for the optional attributes?

--Beman