Chris ( Val ) said:
<snip>
> I think I can understand your reasons for [writing setters that
> return values], but that is a hack in C++,
<shrug> :-)
> and goes against everything we learn about OOP and writing good,
> maintainable and safe code.
Um, *what*? What's unsafe about yielding the old value of a value you're
about to change? At least that way you are providing the *possibility* of
restoring it.
> 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.
I understand and appreciate that throwing an exception is considered The
Right Thing by many people, but that doesn't mean I have to agree with
them. I think throwing an exception is just plain irresponsible. (Yes, we
could have a flame war about this, but I hope we're not going to. I don't
insist that anyone changes their mind on my account.)
> It's just too easy to forget how many times it was set, and if it was
> a newx or oldx value, and where in the code a mistake was made.
All mistakes are too easy to make. That doesn't mean we *have* to make
them. For example, it's pretty darn easy to put v = i++ instead of v = ++i
(or vice versa), but that doesn't mean we should avoid using ++.
>> int oldx = p.getx();
>> p.setx(newx);
>> dosomethingwith(p);
>> p.setx(oldx);
>
> This is *much* better, as the 'getter' will always return the current
> value, without chance of returning anything other than that.
No, it's not much better at all. In my view, it's a little bit worse. It's
more code, and it's less elegant.
>
> But why put 'p' through all that trouble?
>
> What you have written above seems to require only a tem****ary, and
> could be written as follows, given an appropriate constructor is
> implemented:
>
> dosomethingwith( point( newx ) );
That's fine if you're only changing one value at a time, but gets a touch
clumsy if you're recursing through a lot of permutations in a
backtrackable algorithm (eg DFS).
> // p is untouched...
>
> At worst, create a new point as a tem****ary object:
>
> point p2( n, n );
>
>> but only at the expense of an additional function call.
>
> And the advantage of safer programming, easier debugging, maintenance
I'm not convinced of any of those...
> and conformity to accepted principles and practices.
....and I'm wary of this one. Yes, we should conform to the language spec,
and yes, "accepted principles and practices" are all very well and
actually fairly im****tant, but if we never challenge them, we're
effectively assuming that they are already perfect, which is
extraordinarily doubtful.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www.
+rjh@[EMAIL PROTECTED]
users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
|
