RE: [boost] Re: Design for a file system library

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-02-26 15:56:37

From: Jan Langer [mailto:jan_at_[hidden]]
> 
> On Tue, 26 Feb 2002, dylan_nicholson wrote:
> >--- In boost_at_y..., Jan Langer <jan_at_l...> wrote:
> >We need something better than require() for setting multiple
> >properties:  Let's say I wanted to set the owner and group at the
> >same time, and doing both together at the OS level would take half as
> >long as doing one then the other.
> >The best I can think of is:
> >
> >   attribute_set a(my_file_name);
> >   a.defer();
> >   a.set<owner>("dylan");
> >   a.set<group>("users");
> >   a.commit();
> >
> >defer() and commit() again are completely optional.  If you only need
> >one attribute, or don't care about the potential performance hit,
> >then leave them out.  I would probably go further and say an
> >implementation is allowed to ignore them too, so that failing to call
> >commit() after defer() has an implementation-defined outcome.
> 
> why not drop the defer() and say that calls to set can always be
> buffered. you can also commit (or flush) them be hand or at least on
> destruction of the attribute_set.

That works for setting attributes, but what about when reading attributes?
It would be nice to specify that you want to read some set of attributes
before reading any in order to gain performance on those systems which can
spend the time retrieving only what is desired and can skip retrieving what
isn't desired.  Thus:

    a.read<owner>();
    a.read<group>();
    // reads all desired attributes and then returns owner
    a.get<owner>();
    a.get<group>(); // returns group
    a.read<size>();
    // rereads attributes, including size, then returns group
    a.get<group>();
    a.get<size>(); // returns size

IOW, calling get() checks to see if the set of attributes to load is dirty,
reading them if so, then returns the requested attribute.  The downside is
that this approach gets quite verbose.

> >(btw I really don't like the free function notation - it just looks
> >atypical.  I understand it's purely a syntactical thing, but I think
> >you'll find it matters more in many developers minds.  Also in this
> >case for implementations that do honour require/defer/commit it
> >probably requires a template friend declaration, which is not a good
> >idea).
> 
> it does not require any friend declarations. and i don't see why
>   a.get <size> ()
> looks (or is) better than
>   get <size> (a)

Many are quite comfortable with object.function() calls than with
function(object) calls.  The discomfort comes from the thinking that if you
go to the trouble of creating an object, and then all operations on it are
non-member functions, then you're writing C, not C++ code.

> another thing is that also calls of
>   get <size> ("file.txt")
> must be possible without an attribute_set.

That's a great argument in favor of the non-member function approach.

Rob
Susquehanna International Group, LLP
http://www.sig.com