Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!caen!spool.mu.edu!agate!forney.berkeley.edu!jbuck
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: comp.lang.c++
Subject: Re: MEMBER ACCESS
Message-ID: <1991Jun3.180222.19093@agate.berkeley.edu>
Date: 3 Jun 91 18:02:22 GMT
References: <97edfa6b92f028446f60@rose.uucp> <2351@media03.UUCP> <14893@ector.cs.purdue.edu>
Sender: root@agate.berkeley.edu (Charlie Root)
Reply-To: jbuck@forney.berkeley.edu (Joe Buck)
Organization: University of California, Berkeley
Lines: 31

In article <14893@ector.cs.purdue.edu>, svb@cs.purdue.EDU (Stephan Bechtolsheim) writes:
|> I happen to agree with the original request, and that's
|> to have the possibility to declare read only access. As far
|> as I am concerned
|> 	A.get_x()
|> doesn't read as well as does
|> 	A.x
|> I also admit: it's a matter of taste.

No, it's not just a matter of taste.  If the language allowed you to
declare read-only data member access, get_x() would still be superior.

Why?   Because real programs have a life cycle; they need to be maintained,
updated, modified, debugged.  By exporting x as a public (even read-only)
data member, you then must maintain that interface, even if, in a later
revision, you really want to get rid of x altogether but it's still
possible to compute the value x WOULD have for backward compatibility
(example: you decide to represent the position in polar coordinates
instead, so you have r and theta instead of x and y.  You can still
implement get_x, as { return r * cos(theta);}.  If get_x is called
more frequently than theta is modified, you could add cos_theta and
sin_theta members for efficiency.  But the writers of other modules
shouldn't need to know about your implementation details.

If you're going to have any hope of writing maintainable programs, you
need to use the principle of information hiding.


--
Joe Buck
jbuck@galileo.berkeley.edu	 {uunet,ucbvax}!galileo.berkeley.edu!jbuck