[boost] Re: data accessor/decorator

From: jsiek_at_[hidden]
Date: 1999-12-08 23:01:31

Ok, I'll send up the white flag on this one :)

Dietmar Kuehl writes:
 > Hi,
 > At 12:02 PM 12/8/99 -0500, jsiek_at_[hidden] wrote:
 > >So the main reason Dietmar does not like operator[] is that you need a
 > >proxy class to implement the various semantic flavors that are needed.
 > 
 > The proxy is one reason why I'm opposed to the 'operator[]()'. There
 > is another reason: 'operator[]()' needs to be a member function, it
 > cannot be a global function. Thus, it is impossible to add a version
 > taking a different kind of descriptor, eg. a wrapper around the original
 > descriptor, as argument. Why would somebody want to wrap a
 > descriptor? For example to cope with a temporarily modified graph
 > which somehow deals with the additional nodes (a simple example: a
 > network with added super source and super sink). The added function
 > could inspect the descriptor and depending on its value delegate the
 > request to the original property accessor or to some other accessor.

Yes, this is a similar reason to why I did not want the adj() etc.
functions to be member functions of the graph object. global functions
are almost always better and more generic. If only operator[] could be
a global function!

 > The use of read/write accessors is quite common: Basically all flags
 > and temporary values use read/write accessors. However, even the
 > simplest of these uses, eg. Boolean flags, are rather likely to use
 > accessors which do not provide access to an lvalue. For example,
 > to avoid going through the whole graph to clear a flag in multiple
 > calls to an auxiliary algorithm (eg. a path search in the augmenting
 > flow algorithm) a simple technique using an integer can be used:

Ahh, yes we do this in GGCL too. It would be easier without proxying.

Cheers,

Jeremy