Re: [boost] Filesystem attributes

From: Dietmar Kuehl (dietmar_kuehl_at_[hidden])
Date: 2002-03-02 22:01:06

Hi,
Beman Dawes wrote:

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

Position and property access are two orthogonal things which should
not be lumped into just one entity! Most of the problems concerning
iterators in the standard library are from the misconception that
iterators should do both positioning and property access: The standard
iterators are implementing two completely separate concepts.

You are doing the same to the directory iterator. I think this is rather
wrong, especially as the set of attributes applicable to things like
directory entries is not at all fixed! For example, I would consider it
reasonable to define a file attribute "is_graphic" for an application
dealing with graphics objects (jpegs, gifs, etc.). Do you really
consider it better to do something like this

   if ( get<is_graphic>( itr ) ) // is_graphic(itr), ...
     process( itr->pathname() );

than

   if ( get<is_graphic>( itr ) )
      process( get<pathname>( itr ) );

My personal perference is a consistent notation which happens to be
possible only with the latter approach... Also, I just though of it, it
is unclear what encoding the path name has and whether it matches the
needs of the user. That is, it is actually

   get<pathname<wchar_t> >( itr )

or, in a context where narrow character are more desirable

   get<pathname<char> >( itr )

How do you address this issue with the member function? Ah, of course,

   itr->pathname<wchar_t>()

or, if the iterator happens to be a template argument,

   itr->template pathname<wchar_t>()

Well, beauty is in the eye of the beholder...

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 file's
name is more or less an arbitrary choice which comes in handy for simple
uses. For more complex uses, the user either would access the various
property directly or use an appropriate adaptor or, with a slight
redesign, passes the desired property as a template argument which just
defaults to the file name (I think this is a reasonable default).

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

Iterators confuse two separate concepts! Separating property access from
object identification clears things up. Of course, everybody is now used
to iterators confusing these two things liberally but this should be
corrected since it causes all kinds of problems. To me the only question
is how the interface is effectively supposed to look like. The question
is not whether iterators and property maps should be separated: That's a
given! For me, at least...

Maybe I'm too used to property maps... On the other hand, the current
iterator model is, IMO, too problematic to continue with it in the long
term and property maps address most of the problems. Since I have
claimed several times that there are problems with the current model
which are fixed by separating iterator and property maps without
pointing the problems out, here is a list of problems:

- const_iterator vs. iterator:
   - can these be compared and/or converted?
   - can both be used to specify positions in containers?
   - how to get an iterator from a const_iterator?
- value_type
   - how to deal with multiple values? map's approach does not scale and
     causes eg. problems to key/value organization?
   - how to search for key in a sequence of pairs (eg. to implement a
     vector based map)?
   - how to sort a container with polymorphic object but with a value
     like feeling? (the problem is the missing distinction between the
     value for the comparison and the holder maintaining the object)
   - how to create a proxy container?
- harder to extend:
   - creating eg. a filtering iterator requires details on iterator's
     member functions
   - how to add a derived attribute and use the iterator with find on
     the derived attribute?

This list is just made up of the problems I remembered while writing it.
Browsing the library DR list would likely extend this list. ... and
*all* of these issues are solved by separating iterators into iteration
(ie. position identification only) and property access! You can hack
around most of these issues but not around all of them...
-- 
<mailto:dietmar_kuehl_at_[hidden]> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>