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,b47b15fda2aeb0b2 X-Google-Attributes: gid103376,public From: jsa@alexandria (Jon S Anthony) Subject: Re: Two ideas for the next Ada Standard Date: 1996/09/06 Message-ID: X-Deja-AN: 179017058 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-06T00:00:00+00:00 List-Id: In article <322D6D79.7317@ehs.ericsson.se> Jonas Nygren writes: > the following type of code is often found in Ada: > > generic > type T is private; > type TA is access all T; -- this is what I mean with carrying > package P is.... -- with you > > Suppose that we after the instantiation of this package > need to do some conversion to the access type passed to P, > when e g extending an existing application, using: > > (2) > generic > type Object(<>) is limited private; > package System.Address_To_Access_Conversions is > pragma Preelaborate(Address_To_Access_Conversions); > (3) > type Object_Pointer is access all Object; > function To_Pointer(Value : Address) return Object_Pointer; > function To_Address(Value : Object_Pointer) return Address; > (4) > pragma Convention(Intrinsic, To_Pointer); > pragma Convention(Intrinsic, To_Address); > end System.Address_To_Access_Conversions; > > How do we use Object_Pointer together with our existing access type > without conversion. Of course we could reorganise all our code OK, that is true. But this is a very strange example. Are you saying that you've got these sort of access<->system.address conversions going on all over the place?? If so, that still sounds like a basic/fundamental error. > Further how do one end up with one and only one access type > if one have to instantiate multiple packages that declare their > own access types. Why would you _want_ such an access type???? That just leads you down the road to having weird reference problems. Just like in C/C++... > And no, renaming via subtypes don't help you. In the example you give: correct. > > 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. > > This is too crude, an either-or approach. I want to be able to control > the accessability for each call. I know you have some concerns here, I just can't make them out. I don't mean simple language mechanics, but rather issues about what you are really trying to achieve. There is no way in any language that is readily available that you can gurantee the sort of thing you seem to want in the _implementation_ of an interface. > > object designated by the parameter, but you can't assign it. This is > > rather more secure than the analog C++ where you get a small piece of > > this with const T* arguments. > > Well, I suppose you have missed the 'const T* const'. No, this doesn't guarantee anything. The function can change the argument with very little effort. Actually, basically no effort. > What I want is similar to C++'s: > > struct T { > void p1() const; // the object cannot be modified inside P1 > void p2(); // the object can be modified inside P2 > ... > }; This does not guarantee anything. p1 can change the object very easily. You can say, "hey no fair casting or whatnot". I say, why not? It's part of the _implementation_ of T. The sort of thing you really want is to prevent a _client_ from doing this. That is easy to do in Ada. > Yes, I guess so. The C++ example above but in Ada with access types: > > type T is tagged.... > > procedure P1 (Obj : in T); -- Obj cannot be modified inside P1 > procedure P2 (Obj : access T); -- Obj can be modified inside P2 > > calling: P1(Obj.all); > P2(Obj); > > Perhaps not a big deal, but the asymmetry of the solution is > very ugly in my eyes. Well, yeah it is ugly and weird. In fact it is really weird especially as P1 can _easily_ change Obj if the implementor wants to, as it is part of the implementation of T and knows all about its structure and representation. There is no guarantee here. It is up to the implementation to not screw you over. > If we could have written: > > procedure P1 (Obj : access constant T); This really doesn't help at all. Even with this you can in P1 change Obj.all - no problem. > We could then call P1(Obj). Everything would then have been > symmetrical and beautiful (again in my eyes). I suppose, but it wouldn't help you achieve what you seem to want to achieve. > And I can't see that it would have been too difficult to implement > in a compiler. I agree. Especially since type T_Const_Ref is access constant T; is already there and behaves in the way you want. But note: procedure P1 (Obj : T_Const_Ref); can't _guarantee_ what you want either. Sure, it is a very strong indication that Obj.all won't be changed, but since P1 has the representation of T, it still might. Note that I am also calling this out as different from some client trying to pull this sort of thing as they can't see the implementation. Of course, they could still try something nefarious behind your back, but then all bets are off and they will get what they deserve. > > That sounds correct as you never had what you really seem to want in > > in C++ either. > > In this case C++ have what I want. There are many other aspects Well it has "access const" parameters, but these don't look anywhere near sufficient to do what you seem to want: Guarantee that the _implementation_ of a type/class won't change a give instance in a given operation. > of C++ which I do not like and when I add up pros and cons for Ada > and C++ then Ada wins (again this is as seen with my eyes). That's > why I bother about Ada at all - I want Ada to become 'better'. > A side note: perhaps all these years in the shadow of C and C++ > have resulted in that Ada proponents automatically takes a > defensive stand as soon as Ada and C/C++ are mentioned in the If there's a problem of this sort it is due to the overwhelming non-understanding of Ada in various circles conjoined with those same circles being more than willing to make incorrect statements about it as though they are fact. You don't seem to be one of those. In this case, I just don't understand why you think you need to or even _can_ do what you seem to want. In C++ or Ada. Or for that matter, Eiffel, Sather, Lisp, ... > construct. Perhaps Gnat could serve as a test environment for new > language concepts much as gcc does for C. That's one of the reasons why it is there. Go for it! /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com