RE: [boost] Filesystem attributes

From: Jeff Garland (jeff_at_[hidden])
Date: 2002-03-03 12:29:02

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

> If people would prefer to have 'operator*()'
> return a full path name it would be fine for me as well: I don't care
> much about 'operator*()' - except that it should do something easy to
> use if we have it in the first place.

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.

> The directory iterator's actual data is handle on a directory entry
> which caches the entries system attributes.

Ahh!  So how do the get/set operations get access to this data structure if the
only thing interface of the iterator is to return a string?  Obviously there is
another interface into the iterator....

> Since the set of attributes
> is open (it can be considered to be open for basically all sequences
> because it is for all sequences reasonable to view the sequence as a
> sequence of derived data) it does not make sense access attributes via
> member functions [directly]: This mere causes to consider some
> attributes to be more important than others. ... and the list of
> attributes *you* consider to be important does not match mine: To me the

My criteria for dir_entry is not what you or I consider important.  My criteria
are the minimum set of capabilities that must be implemented for client code to
portably access filesystems that consist of files and directories.  Nothing
more, nothing less.  IME this means the name of the file with and without the
path adornment and whether the entry points to a file or directory.

> The whole property map issue is to avoid special handling of attributes.

I'm not generally in disagreement with the property map approach...

> You are implying that I need non-portable code to figure out whether a
> file is gif, jpeg, ...? I don't think so.

See my response to Jan....

> >>The reason that the directory iterator has a value type at all is just
> >>that iterators [falsely] need value types in the first place!
> >
> > The name is still a string value, no?
>
>
> As I spelled out already in the previous mail: The value type does not
> at all matter to majority of the operation!

Ok, I think I'm following, but it was non-obvious to me from the previous mail
that the iterator was holding an opaque data type under the covers for use by
the property accessors....

> It is just a special access
> method for a special attribute. Whether it is a string, a bool, an int,
> or an arbitrary complex data structure does not really matter at all: It
> is just there to make the directory iterator an iterator according to
> to the standard requirements. And a string representation of the file
> name seems to be a pretty convenient approach - much more convenient
> than the structure you suggested.

Obviously I don't agree....

> > The pure functional approach is going to need to access the disk
>
>
> As strange as it may seem: No, I'm not at all forgetting this issue!
> Just because the value type is a string it does not mean that the
> string is the only entity stored in the iterator's representation - and
> it is not in my implementation. Instead, there is an access method the
> corresponding property maps use to get at the internal representation.

My not understanding this is key to the confusion here!

> What I had forgotten about was the indirection taken by property maps,
> ie. that they use a "key" rather than the iterator itself (I have always
> used iterators directly instead of a "key"). This would, however, settle
> what 'operator*()' is returning: A reference to an opaque structure. The
> corresponding property maps know what to do about this structure to
> retrieve the attributes. This would also fix the problem of having two
> overload for directory iterators and directory entries as the directory
> entry would also provide access to a reference to the opaque structure
> for use as a key by the property maps.

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

Jeff