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