phil.calvin@rose.uucp (PHIL CALVIN) (05/30/91)
A language feature I'd like to see...
A class has certain data members, for efficiency reasons, I would like
to grant the USER read-only access.
EX:
class COORD
{
public:
// Don't modify just read..
int x,y;
...
};
Obviously, the comment does little more than _encourage_ the user to
modify the value. My proposal is to have language support for this
concept:
EX:
class COORD
{
const public:
int x,y; // Not an lvalue, compile will flag as errors.
const protected:
int a,b; // Same thing, derived class may read, not write
...
}
A couple of points:
1. Obviously const private makes no sense
2. class members and friends always have write access (unless, of
course the object is const)
Any remarks/flames etc?? Has this facility been discussed and
rejected??
If so, would someone summarize reasons and email me??
Thanks..
..Phil
---
pkr@media03.UUCP (Peter Kriens) (06/03/91)
Ahh, somebody wants to add just one xtra keyword to th elanguage: > A class has certain data members, for efficiency reasons, I would like > to grant the USER read-only access. > EX: > class COORD > { > public: > // Don't modify just read.. > int x,y; > ... > }; I think this shows a bit the problem with C++, adding goodies to the language which are rarely really usefull and can be implemented perfectly with the language as it currently is. Jus specify two inline functions which return the values. Then you have got your read only access, and as an added benefit, if you later decide to keep you coordinate as a polar, then your existing users won't break. While if you had given them read access, you were forced to maintain those instance variables. And for performance, an inline function should be about equal in performance from giving access. Peter Kriens
niklas@appli.se (Niklas Hallqvist) (06/03/91)
phil.calvin@rose.uucp (PHIL CALVIN) writes: > A language feature I'd like to see... There is language support for this already... > A class has certain data members, for efficiency reasons, I would like >to grant the USER read-only access. > EX: > class COORD > { > public: > // Don't modify just read.. > int x,y; > ... > }; > Obviously, the comment does little more than _encourage_ the user to >modify the value. My proposal is to have language support for this >concept: class COORD { int _x; int _y; public: const int& x; const int& y; COORD() : x(_x), y(_y) {} }; int main(int, char**) { COORD p; int X = p.x; int Y = p.y; // p.x = X; // ERROR! // p.y = Y; // ERROR! } As you can see, no new language constructs are needed. Niklas -- Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!sunic!chalmers!appli!niklas
svb@cs.purdue.EDU (Stephan Bechtolsheim) (06/03/91)
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.
jbuck@forney.berkeley.edu (Joe Buck) (06/04/91)
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
mmk@d62iwa.mitre.org (Morris M. Keesan) (06/04/91)
In article <758@taumet.com> steve@taumet.com (Stephen Clamage) writes: > svb@cs.purdue.EDU (Stephan Bechtolsheim) writes: > >As far as I am concerned > > A.get_x() > >doesn't read as well as does > > A.x > > You can name the private data member priv_x and the access function x(). > This leaves you with A.x() for reading the data. > > In another article, Joe Buck gives an excellent summary of why in general > you don't want to provide direct access to data members. And you can also, if you really want to see A.x instead of anything with (), you can name the private data member priv_x, the access function get_priv_x(), and #define x get_priv_x()
steve@taumet.com (Stephen Clamage) (06/04/91)
svb@cs.purdue.EDU (Stephan Bechtolsheim) writes: >As far as I am concerned > A.get_x() >doesn't read as well as does > A.x You can name the private data member priv_x and the access function x(). This leaves you with A.x() for reading the data. In another article, Joe Buck gives an excellent summary of why in general you don't want to provide direct access to data members. -- Steve Clamage, TauMetric Corp, steve@taumet.com