arn@apple.com (Arn Schaeffer) (07/21/89)
I think the addition of const member functions is a powerful and necessary addition to the language; however, the semantics of a const member function declaration is essentially a statement about storage. That is, a const member function will not cause the actual bits in the object to change. For a simple non-virtual "getter," a const member function is an easy statement to make. Unfortunately, providing virtual const member functions is a bit tricky. It forces the class designer to make an implementation decision for all subclasses. Sometimes this is necessary because you need (or want) to make a statement about storage. Sometimes, you just want to make a statement that the object hasn't changed in any way that is perceptible through the interface. For example, I might have a member function that returns some information and caches the result in the object. Obviously, this can't be a const member function using the current definition of const, yet there is an important statement that the class designer would like to make (this object does not change in any way perceptible through the interface) that cannot be made. I understand the motivation about making const a statement about storage. I also think that it is tremendously valuable for non-virtual "getters." There are many general classes that I have developed which I am reluctant to make such a strong statement about storage (I don't want to tie the hands of subclasses) yet I'd be very willing to make an important statement that no perceptible change has occured to the object. Is it (will it be) possible for me to make the statement I'd like to make? In my work it seems that most of the time I don't want to make the statement about storage just about interface. The opinions expressed are not necessarily those of Apple Computer. Arnold Schaeffer Apple Computer, Inc. arn@apple.com
ark@alice.UUCP (Andrew Koenig) (07/22/89)
In article <2943@internal.Apple.COM>, arn@apple.com (Arn Schaeffer) writes: > Is it (will it be) possible for me to make the statement I'd like to make? > In my work it seems that most of the time I don't want to make the > statement about storage just about interface. Well, you can use a cast to remove the constness of `this' if you insist. Opinions are divided, however, about whether such an operation should always be guaranteed to work. -- --Andrew Koenig ark@europa.att.com
dog@cbnewsl.ATT.COM (edward.n.schiebel) (07/24/89)
From article <9662@alice.UUCP>, by ark@alice.UUCP (Andrew Koenig): > Well, you can use a cast to remove the constness of `this' > if you insist. Opinions are divided, however, about whether > such an operation should always be guaranteed to work. > -- I would be very sad to see this removed. I have const member functions which do not change the external view of an object, but do manipulate some internal state information. For what its worth, I feel the user of a class should view a const object as constant from her perspective, not from a storage in memory point of view. - Ed Schiebel
arn@apple.com (Arn Schaeffer) (07/24/89)
In article <9662@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes: > Well, you can use a cast to remove the constness of `this' > if you insist. Opinions are divided, however, about whether > such an operation should always be guaranteed to work. Your solution works great if I ALWAYS want const to make the "object hasn't changed in a way perceptible through the external interface" statement. I guess what I wanted was a way to do both things. It seems to me that there needs to be a way to make the statement at the interface level otherwise clients who expect const to be a storage statement will be disappointed (or bus error.) Perhaps this statement could be made with the addition of yet another type specifier. For example, "const" could make the statement that the storage for this object is not mucked with and "stable" (or some better word) could make the statement that this object isn't mucked with in a way perceptible through the external interface. Arn Schaeffer Apple Computer arn@apple.com The opinions expressed are not necessarily those of Apple Computer.