Re: [boost] Filesystem attributes

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-03-02 10:58:07

At 07:41 AM 3/2/2002, Jan Langer wrote:

 >On Fri, 1 Mar 2002, Beman Dawes wrote:
 >>*  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
 >
 >i would drop (3), because inheritance means an is-a-relation and an
 >iterator is not a value-type but usually a pointer to a value type.
 >>to be used to get just the filename.

(1) is really the only practical candidate, so please ignore the 
others.  Even if (3) works (and you may be right that it doesn't), it is 
just too kinky for what should be a pretty pedestrian library. (2) results 
in convoluted syntax ( "itr->directory_entry->filename()" rather than 
"itr->filename()" for common usages, yet I can't see any offsetting 
advantages.

 >please explain why there is a need for a relationship between
 >directory_entry and directory_iterator at all.

If there is no public relationship, I see several problems:

* The model of a directory_iteratory iterating over only the filename seems 
wrong to me.  The attributes are attributes of the directory entry, not the 
iterator.  It more or less forces all directory_entry operations to be 
performed as non-member functions, which seems limiting.  For example, a 
post from Jeff Garland pointed out that sometimes what is required from an 
iterator is full pathname rather than filename.  What could be more natural 
than having both pathname() and filename() directory_entry members?  There 
is no natural way to do that with directory_iterator::value_type of just a 
string returning the filename.

* Every library or user supplied function (remove, copy, move, foo, ...) 
has to overload arguments on the iterator type (which I consider a burden 
and unneeded complication), or failing that, force users to write uglier 
syntax:

      foo( get<pathname>( itr ) );  // ugly for required attributes.

      foo( itr->pathname() );       // better

* I'm guessing the "no relationship" model is harder for users to 
understand.  I know it confused me for a fairly long time, as I kept 
looking for a relationship that wasn't there.

Your question is certainly valid; I don't think it is an open and shut 
case. But to me iterators should just iterate and be dereferenced; they 
shouldn't also be a direct gateway to attribute property maps. That's 
confusing two separate concepts.

--Beman