Filesystem attributes

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-03-01 14:23:46

I've just reviewed a series of helpful postings on attribute related issues 
from Jan Langer, Jeff Garland, Dylan Nicholson, and Robert Stewart, re-read 
Dietmar Kühl's dir_it documentation , and the Boost Property Map docs 
(updated version in CVS).

For dir_it see 
http://groups.yahoo.com/group/boost/files/filesystem/dir_it-20010909.tar.gz

For updated version of Property Map, see 
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/property_map/property_map.html?rev=1.12&content-type=text/plain

Conclusions
-----------

(The focus is on functionality, first, then usability.)

*  The Attributes concept being discussed is very similar to Dietmar's 
original basic_dir_entry.  I'll call it directory_entry for ease of 
discussion; that would actually be the typedef name for 
basic_directory_entry<char>.

Because a directory_entry contains all the detail attributes, it can be 
created once and then queried/modified repeatedly, solving many of the bulk 
read/write problems posed in discussions.  A "commit" or similar function 
is definitely needed to fully solve these problems.  Since set() functions 
would work on directory_entry rather than names, the fact that a 
directory_entry commit() is needed to actually apply the attributes back to 
the external directory will be much less surprising.

*  In Dietmar's design, directory_entry was only related to a 
directory_iterator by the fact that both use the same opaque representation 
class. There was no containment or inheritance relationship.  Since a 
directory_entry couldn't be gotten from a directory_iterator, functions 
such as set/get had to be overloaded for both. I found that part of the 
design confusing.  As we add additional functions, those overloads become 
more of a problem, particularly if we need still more overloads to improve 
usability.  See below.

It seems to me other relationship alternatives are well worth exploring:
  (1) directory_entry is the value_type for a directory_iterator, or
  (2) a directory_entry is contained within a directory_iterator,
      and is publicly exposed, either directly or by access functions, or
  (3) a directory_iterator is inherited from directory_entry.

(1) is more in keeping with the usual practice. Both (1) and (3) ease 
overloading functions (See next bullet). (3) saves having to write "*" to 
get at the directory_entry from a style (1) iterator, and leaves "*" free 
to be used to get just the filename.

*  For many of the free functions like remove/move/etc, we will want to be 
able to call with several argument types.  Relationships 1, 2, and 3 each 
need to be evaluated in terms of how complicated they make the overloading 
of the free functions.  The two argument functions may be the worst 
cases,  but for simplicity just consider:

    remove( "my_file" );
    remove( my_file_string );
    remove( my_dir_iter );  // or remove( *my_dir_iter ) with (1)
    remove( my_dir_entry ); // same overload as prior with (3)

*  Unless I'm really missing something, the Boost Property Map Library 
should be used at least for the tags and traits. If there is something 
wrong with the Boost Property Map Library, we should fix it rather than 
rolling our own.  I personally dislike "get" and "set" as function names, 
preferring "property" for both, but that is a different issue.

Comments?

--Beman