From: Gabriel Dos Reis (dosreis_at_[hidden])
Date: 1999-12-09 00:25:05
| 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!
Althought I agree with DK, I think the fact that operator() should
be a member function isn't really a big constraint, assuming I didn't
miss anything :-) Since you plan to use proxies, what about making
operator() a template member function and forward the actual
operation to be done to a global function?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk