Re: [boost] Filesystem attributes

From: Jan Langer (jan_at_[hidden])
Date: 2002-03-02 14:24:37

On Sat, 2 Mar 2002, Beman Dawes wrote:
> >>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
>
>(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.

i do also think that (1) is the best candidate of this three but not the
best at all.

> >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.

you mentioned the pathname as a member of directory_entry but i think
this is a property which is not needed. a function absolute() will do
the same and is useful for several other things.
        foo (absolute (*itr));
or 	foo (compose (dir, *itr));

and pathname is actually no real property like size or is_directory. it
can also be part of the iterator itself. i think the public interface of
directory_entry would grow too large if all required attributes have
their own member-function (perhaps with some require and commit
functionality).
        foo (itr.pathname ());

another point is expensiveness. there is no way to do a simple and cheap
find operation in a directory like
        std::find (begin, end, "file");
because on every iteration cycle a probable large property-map-objekt
must be build and destructed.

in general i think we should keep the four things
        - file ops
        - path ops
        - iterating
        - attributes
as much seperated from each other as possible. the user will be forced
to write a bit more but the design will be clearer and easier to learn.

of course i am not an experienced library programmer. i'm actually no
real programmer at all. though i will accept the result of the
discussion anyway because i trust in your experience but i'm not really
convinced yet.

-- 
jan langer ... jan_at_[hidden]
"pi ist genau drei"