Boost logo

Boost :

From: Dietmar Kuehl (dietmar.kuehl_at_[hidden])
Date: 1999-12-08 07:27:18

At 02:40 PM 12/7/99 -0500, jsiek_at_[hidden] wrote:
>How about "property accessor" as a compromise on the
>name for data accessors/decorators?

That's an excellent compromise: I even like it better than data
accessor :-) It is more to the point and "property" does have
both a singular and plural. "Data" only has one of them and I can't
always remember which...

The interface for property accessors is still somewhat open and
actually a little hard to define with respect to one of the arguments,
namely the object used to identify the object whose properties are
to be accessed: This can be very general ranging from a variaty of
iterators to simple integers.

I haven't seen any comment on the 'operator[]()' issue. Thus, I will
assume that there is no objection to the use of the 'get()' and 'set()'
in algorithms to access the properties.

In the context of graph algorithms, it is desirable that a property
accessor can be "indexed" using different kinds of identifiers for
the objects whose properties are to be accessed. For example, the
accessor for a node property should both be indexable using either
a node iterator or a node descriptor. In other context, property
accessors might also be indexed using an integer (ie. an index :-)
closing the gap between property accessors and array like

In the requirements description below I will use 'IT' for "index type"
and 'it' to be an object of such an index type. Since the index type is
relatively open, I leave it open which types can be used and for the
context of graph algorithms this has to be defined separately. It is
worth noting that the set of index types used with a property
accessor can be extended by overloading the corresponding 'get()'
and 'set()' functions!

- PA is a property accessor type
- pa is an object of type PA
- T is the value type of PA
- val is an object type T

There are four categories of property accessors: read, write,
read/write, and lvalue property accessors. All four categories share
some common requirements for meta data and object management:

- PA::value_type - a typedef for the value type accessed by the
                                    property accessors
- PA::category - a typedef naming the category of the property
                                    accessor, similar to the iterator catagory
- PA(pa) - a copy constructor is required (and an accessable
                                   destructor is assumed)

Neither default constructor nor copy assignment are required!
Although some property accessor are actually more like traits and
do not store any data, a corresponding object is always passed
around: Many useful property accessors do store data, eg. a
reference to a container or references to other property accessors.

- Read Property Accessors
  In addition to the common requirements, read property accessors
  support the following operation:

    val = get(pa, it) - read the property associated with the object
                                   identified by "it"

- Write Property Accessors
  In addition to the common requirements, write property accessors
  support the following operation:

    set(pa, it, val) - write the property associated with the object
                                  identified by "it"

- Read/Write Property Accessors
  Read/write property accessors conform to both the requirments
  for read and write property accessors.

- Lvalue Property Accessors
  Lvalue property accessors conform to the requirements of
  read/write property accessors. In addition, the following operations
  are support

    at(pa, it) = val - write the property associated with the object
                                    identified by "it"
    val = at(pa, it) - read the property associated with the object
                                    identified by "it"
    PA::value_type& val = at(pa, it)
                                  - obtain a reference to the property
                                    with the object identified by "it"

For lvalue property accessors there may also be a requirement for
'operator[]()'. I don't think it is necessary but wouldn't mind supporting
it either.

If there are no or only minor objections which can be incorporated
with this interface, I will document it and submit the documentation
together with a few general purpose property accessors to Boost.
General purpose property accessors can be things like a member
accessors (using an lvalue accessor underneath) and a constant

The document vault at egroups looks very much like something
we could use for providing an editable design document. Once the
documentation is stable it can probably be moved to the Boost site.
I will probably try this later today using this mail a basis for the


Boost list run by bdawes at, gregod at, cpdaniel at, john at