Re: Total Newbie Backward Compat Question

Anand Hariharan <mailto.anand.hariharan@[EMAIL PROTECTED]
> wrote:
> Daniel T. wrote:
> > Bart van Ingen Schenau <bart@[EMAIL PROTECTED]
> wrote:
> > > Chris ( Val ) wrote:
> >
> > Code example under consideration:
> >
> > class Foo {
> > public:
> >    int getValue() const;
> >    int setValue( int v );
> >       // ensure: result == old getValue() && getValue() == v
> > };
> >
> > > I would regard such a setter that returns the previous value as
> > > perfectly valid OOP, if two conditions are met: 1. Having the
> > > setter at all does not blatantly violate the principles of OOD.
> >
> > It blatantly violates the Command-Query Separation principle.
> >
> > > 2. This return value is not the sole means of retrieving the
> > > current value.
> >
> > That's an odd condition, the method in question isn't a means of
> > retrieving the current value in the first place, so of course it
> > isn't the sole means of retrieving it.
> >
> > However, the method *is* the sole means of retrieving that which
> > it retrieves (the value of getValue() before the last time
> > setValue() was called,) and it only works once. Referential
> > transparency is broken.
> 
> I understand this is tangential to the above context, but what do you
> think of std::XXX<T>::erase members where XXX is vector, list, map....

Not tangential at all, its a good example!

> They take an iterator, remove the element corresponding to that
> iterator, and return the iterator for the next element in the
> collection. Would you change the signature?

No, but the reason I wouldn't is because of legacy issues. Too much code 
relies on it.

> Do you consider referential transparency to be broken? Does it
> violate CQS?

Yes, and yes.

> Would you rather force the programmer to find the next element's
> iterator before calling erase, and have erase return void?

Before asking that question think about it. If you are only erasing one 
element, then you ignore the return value and if you are erasing more 
than one element, then the best way to do that (the remove algorithm) 
*also* ignores the return value. The proper solution, it turns out, is 
to *ignore* the return value!

> How about, cout.precision? Am sure there are several such examples.

I expect there are many examples of interfaces in the standard that 
could have been done better, just look at std::string!