On Mar 15, 9:02=A0pm, Francis Glassborow
<francis.glassbo...@[EMAIL PROTECTED]
> wrote:
> Daniel T. wrote:
> > Bart van Ingen Schenau <b...@[EMAIL PROTECTED]
> wrote:
> >> Daniel T. wrote:
> >>> Bart van Ingen Schenau <b...@[EMAIL PROTECTED]
> wrote:
> >>>> Daniel T. wrote:
> >>>>> Bart van Ingen Schenau <b...@[EMAIL PROTECTED]
> wrote:
> >>>>>> Chris ( Val ) wrote:
> >>>>> Code example under consideration:
> >>>>> class Foo {
> >>>>> public:
> >>>>> =A0 =A0int getValue() const;
> >>>>> =A0 =A0int setValue( int v );
> >>>>> =A0 =A0 =A0 // ensure: result =3D=3D old getValue() && getValue()
=
=3D=3D v
> >>>>> };
> >>>> And if I understand the principle correctly, a setter like
> >>>> =A0 bool setValue( int v );
> >>>> would also be in violation, because it both changes the state
> >>>> and returns information about the state.
> >>> Depends on what the ensures clause is, but if the function's
> >>> post- condition is "result =3D=3D true ? getValue() =3D=3D v :
getValu=
e()
> >>> =3D=3D old getValue()" then yes, it breaks the rule.
>
> >>>> Even throwing an exception would violate a strict
> >>>> interpretation of this principle.
> >>> An exception should only be thrown if the contract cannot be
> >>> guaranteed. So no, an exception tells you nothing about the state
> >>> of the object.
> >> Depending on the exception-safety guarantee of the function, it
> >> actually does tell something about the state, in the same way that
> >> the boolean return value above does.
>
> > That depends on how you use exceptions. I don't use them that way,
some
> > people do.
>
> >>>>> 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.
> >>> Really?
>
> >>> =A0 =A0 if ( p.setValue( 7 ) > 10 )
> >>> =A0 =A0 =A0 =A0 cout << "old value was " << ??? << '\n';
>
> >>> You can't determine the old value at the "???" point.
> >> Nor can you if setValue did not return the old value, so that
argument
> >> does not hold.
>
> > Sure it does, the argument is that setValue can only be used once to
> > retrieve the value it provides, the above showed that the argument is
> > true.
>
> This thread begins to smell of dogma. If someone advocated that setters
> should always/never return the prior value I would disagree. Whether
> they do or not should IMO depend on what their purpose is.
If it's a *toy* program, then fine, and from what I gather, the
name 'playpen' dooesn't re****t itself to be of enterprise quality
software :)
In all seriousness, the main issue is whether or not it is acceptable
for writing robust and scalable program code.
While we are at it, can you please explain in brief, what the
advantages
of having are, and why the C++ standards commitie introduced the
'const'
quallifier to member functions, as in: int GetX() const; ?
> In my graphics sup****t for novices I have a type called 'playpen' that
> represents a fixed and deliberately limited graphics window. Instances
> have member variables that 'remember' such things as the current scale,
> location of origin etc.
Having an undo capability is implemented in many graphical programs.
> As such things only control the way graphical data is displayed attempts
> to use out of range values simply saturate. Setters for these features
> all return their prior values so that code such as, for example:
>
> void foo(playpen & p){
> =A0 =A0 // get scale info from user
> =A0 =A0 try{
> =A0 =A0 int oldscale(p.scale(newvalue));
> =A0 =A0 // do something
> =A0 =A0 }
> =A0 =A0catch(...){
> =A0 =A0 =A0p.scale(oldscale);
> =A0 =A0}
> =A0 =A0p.scale(oldscale);
>
> }
What is the real name of the function you are describing above?
It's certainly not foo, and 'oldscale' is not even in scope.
Anyway, what's wrong with:
p.edit();
// Work with p...
p.commit(); or p.rollback(); ?
Where the old object is cloned internally.
> work. And the above is just off the top of my head to illustrate a
> mechanism. Yes It can be written with an extra line to recover the
> oldscale distinct from the line to set the new one and the class does
> have matching getters for each of its setters.
Why does it have matching getters?
Can you explain your thinking as to why you incor****ated them, only
to overlook them with an *AllInOne(*)" chameleon?
> IMHO any time that you have a situation where it is very likely that the
> programmer will wish to change state tem****arily and then restore the
> old state is one where a getter might legitimately return the prior
state.=
I would expect a getter to always legitimately return the *current*
state. If
you want store a specific state, then create another member function
to do
that, using the *getter* itself or clone the object if possible.
--
Chris Val
|
