Path: utzoo!mnetor!uunet!husc6!bbn!rochester!pt.cs.cmu.edu!K.GP.CS.CMU.EDU!lindsay
From: lindsay@K.GP.CS.CMU.EDU (Donald Lindsay)
Newsgroups: comp.lang.c++
Subject: Re: access functions
Message-ID: <1490@pt.cs.cmu.edu>
Date: 21 Apr 88 18:26:43 GMT
References: <8063@apple.Apple.Com> <6590039@hplsla.HP.COM> <11152@mimsy.UUCP>
Sender: netnews@pt.cs.cmu.edu
Organization: Carnegie-Mellon University, CS/RI
Lines: 29

In article <11152@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>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.

The functional approach has other virtues.

Various speed/space optimizations become possible.  The functional approach
allows you to use hidden booleans with names like "initted", "allocated",
"swappedout", "compressed", "shared", "spin_locked", "readonly",
"InSymbolicForm", and so on.  In particular, the functional approach allows
you to start with a straightforward implementation, and then, later, add
hidden cleverness. A library could contain several compatible
implementations.

For example, imagine instrumenting a program, to gather usage statistics.
An access function can be recoded so that it increments a counter.  Without
the functional approach, the recode must touch the using program at every
place where the variable is referenced. (Yes, some compilers can do simple
instrumenting for you .. but can they count how many times a datum was zero,
or was "more than half full" ? )


-- 
	Don		lindsay@k.gp.cs.cmu.edu    CMU Computer Science