Path: utzoo!mnetor!uunet!nbires!ncar!oddjob!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.lang.c++ Subject: Re: access functions Message-ID: <11187@mimsy.UUCP> Date: 23 Apr 88 06:21:30 GMT References: <8063@apple.Apple.Com> <6590039@hplsla.HP.COM> <11152@mimsy.UUCP> <1490@pt.cs.cmu.edu> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 52 >In article <11152@mimsy.UUCP> I wrote the following key line (but probably did not highlight it sufficiently): >>The point, however, is that a variable is always >>a variable, while a function is arbitrary. In article <1490@pt.cs.cmu.edu> lindsay@K.GP.CS.CMU.EDU (Donald Lindsay) writes: >The functional approach has other virtues. [various virtues deleted] Agreed. jima has a point, however: perhaps one should declare that *all* object variables shall be retrieved through access functions, but that argument-free functions should look like variables. This leaves one with the question of how to implement assignments to these. One possible syntax: class c { int var0; int nv0; // counts var0 refs public: int var1; // freely accessible /* * Define access (read & write) functions for var0 that * make it act like var1 without actually being the same * as var1, and incidentally count references too. If * we defined only a read function, or only a write function, * var1 would be a read-only or write-only variable. */ inline int var0() { this->nv0++; return this->var0; } // I never did like implicit references :-) inline int var0=(x) { this->nv0++; return this->var0 = x; } // Here the type of x is implicitly int. // x is any identifier, but there may be only one. c() { var0=0; nv0=0; var1=0; } // `local color' :-) }; Note that cfront already gives a `sorry, not implemented' error for declarations of the form class c { int v; public: int v() { return this->v; } }; -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris