Re: [boost] Filesystem attributes

From: Dietmar Kuehl (dietmar_kuehl_at_[hidden])
Date: 2002-03-03 14:11:03

Jeff Garland wrote:

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

Well, the *current* implementation indeed provides a string with
'operator*()'. However, this is actually a misconception at my side due
to not checking against the concepts defined in the property map library
(or, more precisely, forgetting about a details I used to do differently
while developing the whole concept): The property map takes a "key" not
an "iterator" as position identification ("key" sounds as if there is a
lookup in some form of map but this is not at all the case in many
situations...).

I wasn't explicit about it in the mail you answered to and actually I
did a transistion of how to do things after things had fallen into place
in my mind... The 'operator*()' should return a key useful only for
property maps shipping with the directory iterator implementation and/or
functions effectively delegating to such property maps (eg. property
maps computing derived data on the basis of the existing property maps).

The key type should almost certainly only be declared but not defined:
This way it can be used to maintain operating system data which is not
to leak to user code. This part is actually how I implemented the
directory iterator. However, I used a different function than
'operator*()' to access this data.

Unfortunately, this makes the easy copying approach go away :-( Maybe
the property map library should be extended to a filtering iterator
which provides access to a specific property of an underlying iterator.

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

Sorry: I was unclear about the general approach...

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

Yes, that's it.

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

If I can convince others, too, that property maps are the way to go (the
first attempt into this direction was an article in C++ Report about
"Data Access Templates"...) it will become *the* approach and it would
be in no way obscure. I discussed this issue with several committee
members already but I think either they weren't really interested or
didn't understand the issue or both. Some years back I discussed the
property map approach with Alexander Stepanov (at this time they were
still under the name "Data Accessors") and a lot of time to convince him
of the usefulness of this abstraction - and we could only agree on the
distinction between between reads and writes being important... There is
*more* to this simple abstraction. Much more!

>  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 would go even further and say that the "dir_entry" (if this is what
the opaque type is called) is only declared but not defined in user
visible headers.
-- 
<mailto:dietmar_kuehl_at_[hidden]> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>