Chris ( Val ) wrote:
> On Mar 12, 4:58 am, Bart van Ingen Schenau <b...@[EMAIL PROTECTED]
>
> wrote:
>> Chris ( Val ) wrote:
>>
>>
>> > On Mar 11, 1:21 am, Richard Heathfield <r...@[EMAIL PROTECTED]
>
>> > wrote:
>> >> Chris ( Val ) said:
>>
>> >> <snip>
>>
>> >> > Why did you write setters that return values?
>>
>> >> int oldx = p.setx(newx);
>> >> dosomethingwith(p);
>> >> p.setx(oldx);
>>
>> >> is quite a useful thing to be able to do. You can get the same
>> >> deal with:
>>
>> > I think I can understand your reasons for it, 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'm sorry, but I have identified what I believe to be more than
> enough reasons to justify my position on this matter :-)
>
> Please clarify for me (and our lurkers):
> Would you (and/or have you) personally used that code in production
> work?
I can't remember if I have ever used a setter that returned the old
value, but I do know that I have used functions that both change the
state and return a value. The most obvious one would be a function like
int stack::pop();
that pops a value of a stack and returns the popped value.
To me, there is no fundamental difference with the code Richard
presented, so I would not hesitate to use it in production code.
>
> If not, would you defend it's inclusion in the design of production
> code,
> whether by you or anyone else on the coding team?
>
>> 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.
>> 2. This return value is not the sole means of retrieving the current
>> value.
>>
>> For Richard's example, the second condition is definitely matched and
>> the first might be debatable if we knew more about the context in
>> which the point class will be used. For now, I would just accept it.
>
> Well raw pointers and changing owner****p according to Richard'
> function
> specification can fall under these rules too, but is that a good
> thing?
They can, and therefor are these not the only rules used to validate a
design.
>
>> > 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, then I would strongly
>> prefer a return value over an exception to indicate failure, unless
>> there is reason to believe that the immediate caller will not be able
>> to handle the problem.
>
> Well, you don't have a boolean return value here...
>
> if( p.setx( 500 ) )
> std::cout << "Point plotted.\n";
> else
> std::cout << "Error: - Off the canvas.\n";
>
> ...and since you sup****t Richard' example as being reasonable
> and acceptable code, what will you do here?
The same as I would do if setx() does not return anything.
I would request an interface change for the class.
Probably, I would also need an additional interface to set the extent of
the canvas.
Otherwise, Richard's version would not have survived the first round of
reviews because it has a silent failure mode. (It did not tell the
caller about an inability to fulfil the request.)
>
> How would you get the "SetterGetter" to re****t the success or
> failure of the operation?
If setting can fail, then re****ting the failure is more im****tant than
the convenience of returning the old value.
Richard's code is acceptable, but it mostly remains a convenience
option.
>
> --
> Chris Val
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/
|
