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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b47b15fda2aeb0b2 X-Google-Attributes: gid103376,public From: jsa@alexandria (Jon S Anthony) Subject: Re: Two ideas for the next Ada Standard Date: 1996/09/05 Message-ID: #1/1 X-Deja-AN: 178735997 sender: news@organon.com (news) references: <50aao3$3r88@news-s01.ny.us.ibm.net> organization: Organon Motives, Inc. newsgroups: comp.lang.ada Date: 1996-09-05T00:00:00+00:00 List-Id: In article bobduff@world.std.com (Robert A Duff) writes: > >If you are really this concerned about this why not just make the type > >limited private? Clients can't access the state (except through the > >interface) and they can't assign the things. For _clients_, it is > >strictly _in_ mode. > > But limited is not the same thing as constant. An 'in' parameter is > constant -- it cannot be modified. An 'in out' parameter of a limited > type is NOT constant -- it can be changed. Yes, that is true. I was refering to having access type to a limited type, since "constant" access parameters were the context. But, I agree that I was not too clear: type T is ...limited private; procedure P ( x : access T ); Clients can't change T things unless you (interface provider) give them the ability to do so. If you do, then you should not be too surprised when they do. > Saying clients can't change it (except blah blah blah) isn't much > help -- the fact is it *can* be changed, and it's easy for the > client to change it -- just call something in the package that owns > the type. Well, sure, if you supply accessors to change the thing then of course you can change them. What could possibly be the point of such a comment? The real issue being discussed though is whether the _"owner"_ of the type should be allowed to change such instances in the _implementation_ of the interface when it does not explicitly say it will WITHIN THE LANGUAGE. That is, whether the client should be able to look at the interface and say with _absolute certainty_ that the given operation does _not_ change the parameter. That is a little odd to say the least, as that requires "real" (aka, mathematical) functions. And I don't know of any programming language that does that (not even "functional" languages). That doesn't mean they don't exist (actually they do exist as I designed one with this once - but never implemented), I just don't know of any you can go out and use. > Also, what about the primitive operations of the type? The whole > point of parameter modes is so that you can tell by looking at the > spec, whether or not a given parameter can be changed. ^^^ What about primitive operations? As for the "whole point..." bit, this will never be sufficient. If I want to, I can change an in mode parameter just fine. Behind your back. Sure, you can say that I have violated the contract, but so? The point is, the modes do _not_ _guarantee_ anything. > So, I don't buy the advice "use limited instead of access constant". Well, you don't even have "access constant" so certainly _can't_ use limited _instead_ of this. The idea was to provide an equivalent level of functionality. /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com