Re: Total Newbie Backward Compat Question

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 think I can understand your reasons for [returning a value from
>> > a command], but that is a hack in C++, and goes against
>> > everything we learn about OOP and writing good, maintainable and
>> > safe code.
>> 
>> I am sorry, but I don't see how you come to that conclusion. 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.

Can you give me a pointer to a resource where it is stated that this is
a fundamental principle of OOD?

And if I understand the principle correctly, a setter like
  bool setValue( int v );
would also be in violation, because it both changes the state and
returns information about the state. Even throwing an exception would
violate a strict interpretation of this principle.

> 
>> 2. This return value is not the sole means of retrieving the
>> current value.

I should have left the word 'current' out.

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

It does not work only once.
You can call setValue() as often as you want and each time the call
returns the value as it was prior to that call.

Referential transparency is indeed broken, because setValue() does not
claim to be a query operation. setValue() is a command that happens to
yield a value in addition to its side-effect.
Therefor, this objection is moot.

> So, both of your conditions (after correcting the second one) are
> broken...

I don't agree they are both broken.
And it seems I did not formulate my idea precisely enough.

To me, it is acceptable to return the old value from a setter if
- having the setter at all does not violate encapsulation, and
- there is a corresponding getter for retrieving the value without
changing it.

Note that I am not advocating this kind of design, but I do see it as a
valid design decision.

> 
>> > Some setters are written to return a 'boolean' value to signal
>> > either success or failure, but even that is debatable in some
>> > cir***stances, when compared to throwing an exception.
>> 
>> If it is actually a setter, and not a function that happens to set
>> some values as part of a larger operation,...
> 
> That is getting into implementation details that the interface
> shouldn't expose...

Just about any interface exposes this kind of information, if only by
the naming of the identifiers.

Or do all of your identifiers have meaningless obfuscated names?

> 
> From the client's (user of the cl*****) point of view, there should be
> no difference between a command that "is a real setter" and a command
> that "happens to set some values".

For the person writing the client code, it will often be possible or
even easy to make the distinction, by looking at the names of the
functions and the interface do***entation.
But I agree that for the code itself it should not matter.

Bart v Ingen Schenau
-- 
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://c-faq.com/
c.l.c++ FAQ: http://www.para****ft.com/c++-faq-lite/