Chris ( Val ) said:
> On Mar 11, 9:29 pm, Richard Heathfield <r...@[EMAIL PROTECTED]
> wrote:
>> 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, and such an "unjustifiable" shrug it is :-)
Oh, I think I can justify it (to *my* satisfaction anyway!).
>> > 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.
>
> Well, according to your philosophy, why have a class at all?
> Lets keep everything public and use a C structs only, because
> "is quite a useful thing to be able to do" :-)
Yes, there's a lot to be said for that. Nevertheless, I wasn't suggesting
it. If you've got a way to set a value, and you've got a way to get a
value, I see no harm in providing a way to do both at once. It's not as if
you're opening up extra access to the class - the access is *already*
there, so all you're doing is making it convenient to kill two birds with
one stone.
<snip>
>> I think throwing an exception is just plain irresponsible.
>
> Sorry, but I think that comment didn't have much thought behind it :-)
I'm sorry you think so. :-|
>> (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.)
>
> People will not follow me nor you. Rather, they will adopt the
> generally accepted principles in best practice.
That is, alas, all too often /not/ true. But wise people will follow that
strategy for as long as it makes sense. Rules are there to make you
*think* before you break them.
>> > 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 ++.
>
> Yes, mistakes are easy to make, but why make then easier?
If the payoff is sufficient, why not? As Doug Gwyn once said (and I'm
paraphrasing here because I'm too lazy to look it up): "by making it
impossible for people to do stupid things, you also make it impossible for
them to do clever things". Added flexibility gives added op****tunity to
get it wrong, yes, but it also gives added op****tunity to do something
special. (This is a general observation - I'm not claiming that adding a
return value to a setter gives one the ability to discover a practical
cold fusion technique.)
>
>> >> 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.
>
> Oh, come on, Richard!!!
Hmm? We've crossed swords before, Chris, albeit very amicably, and I seem
to recall that you eventually changed your mind on that occasion. I'm not
saying you're necessarily going to do that this time, but please at least
give me the credit for having thought about this a bit, even if you think
I'm wrong.
> I can only state that in my experience of using C++, I have become
> very comfortable with OOP, and would avoid procedural programming
> at all costs, albeit for small toy programs.
Well, I'm very happy for you. :-) But not everybody thinks like that.
There's more to C++ than OOP.
<snip>
--
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
|
