[boost] Re: data accessor/decorator

From: Gabriel Dos Reis (dosreis_at_[hidden])
Date: 1999-12-09 00:25:05

jsiek_at_[hidden] writes:

| 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?  

-- Gaby