Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!amdahl!pyramid!hplabs!hp-pcd!hplsla!jima
From: jima@hplsla.HP.COM (              Jim Adcock)
Newsgroups: comp.lang.c++
Subject: Re: access functions
Message-ID: <6590042@hplsla.HP.COM>
Date: 23 Apr 88 00:19:25 GMT
References: <11152@mimsy.UUCP>
Organization: HP Lake Stevens, WA
Lines: 90

> >Again, not true -- the issue is public vs non-public, it is not an issue
> >of access functions or not access functions.  Change the meaning of 
> >any part of your public interface, either instance variable or function, 
> >and your class's users will be hosed.
> 
> It is easy to overlook a subtle point.  When you make available a
> value through a member function, the only thing you are putting into
> the public interface is access to a value.  When you make it
> available as a data member you are also putting into the interface
> the operation of changing that value.  Further you are committing
> yourself to the implmentation of this operation as a simple
> assignment.

Could be a valid point.  What I've seen in practice is lots of
programmers writing TWO access routines for "every" instance 
variable in their object.  One to "put" the value, and one to "get"
the value.  And then these people think they're doing "real programming."
My concern is that I think its important to emphasize "engineering
judgement" in the writing of C++ programs -- as opposed to the spouting
of religious dogma.  I've seen too many programmers in other "object
oriented" languages get hung up on "religious" issues -- while ignoring
whether or not their end product solves a real world need by
the time they're done programming.  If in doubt, wrap it in access
functions.  If NOT in doubt, there's no need to wrap it in access
functions.  If C++ is to succeed, it will be because C++ programmers
write great programs!
 
----

> This is true.  The point, however, is that a variable is always
> a variable, while a function is arbitrary.  So if you declare that
> henceforth and forever, anyone can take complexvar.realpart() and
> complexvar.imaginarypart(), and you decide you prefer polar coordinates,
> people can still take the two, while if you declare that anyone
> can simply take .realpart and .imaginarypart, you are stuck with
> rectangular.

True statement.  [Boy am I sorry I ever started using complex numbers
as an example!]

Lets go over this again.

If you have made public .real and .imag of your object, then you the class
writer are committed to making:

   theRealPart = aComplex.real; 
   theImagPart = aComplex.imag; 
   aComplex.real = aRealPart;
   aComplex.imag = aImagPart;

work the way it obviously looks like it should.  If you decide later that
you would like .real to really mean "mag" as in "mag-and-phase" then you
have a problem -- namely what you told the user means "real" now actually
means "mag."  And this means you have failed in your commitment not to
change the meaning of anything in your public interface!

Now lets go over the analogous situation using access functions:

   theRealPart = aComplex.real();
   theImagPart = aComplex.imag();
   aComplex.real(aRealPart);
   aComplex.imag(aImagPart);

Now lets pretend you decide that like in the above example, for SOME unbeknown
reason, you decide you want .real() to really mean the "mag" of the data,
-- then the user is still hosed, 'cause his/her program still won't work.
AGAIN, you have failed in your commitment to keep the meaning of 
everything in your public interface the same.

It doesn't matter whether or not you use access functions.  IF you
keep your committment to keep the MEANING of the various parts 
of your public interface constant, then your class user's programs
will continue to run correctly.

If you do not keep your committment to keep the MEANING of the
various parts of your public interface constant, then your class
user's programs will be hosed.

If you know [using your "engineering" judgment] that you need to
use access functions to meet this commitment of not changing the
meaning of anything in your public interface, then please, use
access functions!

If you know [using your "engineering" judgment] that you do not 
need to use access functions to meet this commitment of not 
changing the meaning of anything in your public interface, 
then possibly your time and effort can be spent more productively
than on "redundant" access functions!

I just feel that this issue is one of judgement, not of the religious
dogma: "use access functions everywhere."