From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,bd40601768eaf8fd X-Google-Attributes: gid103376,public From: Richard D Riehle Subject: Re: 'constant functions' and access constant params (was Re: Array of Variant Records Question...) Date: 1999/09/22 Message-ID: <7s9nd0$cbe@dfw-ixnews17.ix.netcom.com> X-Deja-AN: 528106599 References: <7r5vh3$imu1@svlss.lmms.lmco.com> <37d6a45c@news1.prserv.net> <37d6ccb6@news1.prserv.net> <7r77i8$i08$1@nnrp1.deja.com> <37d7c116@news1.prserv.net> <7r8t21$ov5$1@nnrp1.deja.com> <37d822a1@news1.prserv.net> <7reg02$t83@dfw-ixnews6.ix.netcom.com> <37DE8D09.C863CBC9@rational.com> <7roohh$s6r@dfw-ixnews7.ix.netcom.com> <37e01168@news1.prserv.net> <7rp86o$c6h@dfw-ixnews3.ix.netcom.com> <37E18CC6.C8D431B@rational.com> <7rs8bn$s6@dfw-ixnews4.ix.netcom.com> <37e2e58c@news1.prserv.net> Organization: Netcom X-NETCOM-Date: Tue Sep 21 11:53:52 PM CDT 1999 Newsgroups: comp.lang.ada Date: 1999-09-21T23:53:52-05:00 List-Id: In article <37e2e58c@news1.prserv.net>, "Matthew Heaney" wrote: >Let me preface this discussion by saying that I'm advocating that internal >state changes be allowed only for limited (private), by-reference types. >Of course, internally, there are some state changes, but the client doesn't >know or care about them. That's because the postcondition is > > function Get_Attr (O : T) return Attr_T; > -- > -- Postcondition: return current value of Attr. > >and the postcondition is in fact satisfied. Whether some internal state >changes are made in order to satisfy the postcondition is irrelevant. > >If you don't want internal state changes to occur as a result of invoking >Get_Attr, then how do you state that as a postcondition? Ada does not support post-conditions. I am not persuaded that a comment will have any effect on a client of a design. >> I do subscribe to the idea of ensuring that the client of a query is >> guaranteed that the query will not have side-effects. That, to my mind, is >> not extreme. > >It's not extreme, it's just wrong. We will have to agree to disagree on this. It is a simple proposition. Permit a designer to designate an access parameter to be constant. The client has a guarantee there will be no change to the incoming data. I am not sure why this is so difficult. We would be taking away nothing in flexibility and adding something in terms of the contract. >The sine qua non of the object paradigm is that we don't describe an object >in terms of its representation. We describe the object in terms of what >things you can do to it. No disagreement here. And we describe the the things we can to the object in the form of a contract. The better the contract describes what is legal, what to expect, the better the client understands what to expect of it. >You seem to be saying: > > Query the object, without changing its state. > >But what does that statement really mean? A client doesn't know anything >about an object's state -- he only knows about what he can do to the object >(here, select a value). The client knows what to expect of a contract by what is revealed. Also, the designer of the original function can specify, long before the algorithms for the function are written, the contractual constraints for that function. This could even be useful at the level where a function refers to an abstract class and sets the standard for all derivations and overriding of that function for that class. >How would you even write a postcondition that says "internal state of object >hasn't changed"? You're making a statement about internal behavior, in a >postcondition that describes external behavior. There are no postconditions in Ada, as mentioned earlier. Instead of a post- condition, we can guarantee the immutability of the data, in the specification of the subprogram, by making an access parameter constant. >The other issue is, how should a client use this information? How does >knowing that a selector function returns a value without changing internal >state benefit the client? The information is useful at many different levels. Not the least of those is the original specification a function before the code is implemented. As to the client, knowing that an access parameter to an integer or a floating point value (as an example) is not modified in the function can be a useful thing. Not every access value is a limited type. >(And remember, I'm only talking about internal state changes to limited >private, by-reference types. Objects that are limited are always variables, >never constants.) I am actually not objecting to you notion regarding limited private, by-reference types. >Consider an analogy: people who believe in ESP. When you confront them with >studies that indicate no testing success beyond what's predicted using >probability theory, they say "Well, ESP only works sometimes, and it's hard >to tell when." I am not sure what this means in this discussion. I am certainly not suggesting anything remotely approaching ESP. On the contrary, I am advocating a contract that is a little more explicit vis a vis mutability of access parameters. >OK, fine, but then what would the world look like if there weren't ESP? If >an ESP world looks just like a non-ESP world, then what's the difference? >Why include ESP in the model at all? Just use Occam's Razor to cut ESP from >the model, to keep the description parsimonious. > >What is the difference in the client's world, between invoking > > constant function Get_Attr (O : in T) return Attr_T; > >and invoking > > function Get_Attr (O : in T) return Attr_T; For an in mode parameter, there is no problem and no need for the constant designation. The function that raises a potential problem is one with the specification: function Get_Attr(O : access T) return Attr_T; >As far as I can tell, these worlds look exactly the same. Yes, Matt, yours look exactly the same. But they do not look like mine. Someone else commented on the quest for purity. That is not my quest. Mine is simple and not difficult. Simply, it would be nice to have a way to sometimes guarantee in a function specification that an implementation of that function would not modify the value of an access parameter. Another correspondent noted that const is required in C++ to offset a language problem. We are not talking here of C++. We are all agreed that the problem of modifying an access value can occur in Ada. We simply do not agree that it is worth closing the loophole created by this feature. Richard Riehle