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,5606d8433901738c X-Google-Attributes: gid103376,public From: jsa@alexandria (Jon S Anthony) Subject: Re: Allocating "initialized" limited types... Date: 1996/09/06 Message-ID: #1/1 X-Deja-AN: 178781464 sender: news@organon.com (news) references: organization: Organon Motives, Inc. newsgroups: comp.lang.ada Date: 1996-09-06T00:00:00+00:00 List-Id: In article bobduff@world.std.com (Robert A Duff) writes: > In article , Jon S Anthony wrote: > >> The two cases of initialization are entirely analogous. In the second > >> case, the heap object is being explicitly initialized. Look at the > >> rules in the RM for the two cases -- you will see a lot of parallels, > >> and that's intentional. > > > >Sure, that is indeed how the RM talks about these cases. Doesn't make > >it "right". > > True, it doesn't make it right, but I think it *is* right, nonetheless. > Your complaint was, you can't initialize a limited heap variable in a > way that prevents you from forgetting some components. Initializing > with an aggregate gives that nice feature, but it doesn't work for > limited types. A valid complaint, perhaps, but it's equally valid for > stack objects. Actually, my "complaint" was why are allocator semantics with qualified expressions not simply "creation in place" - forget after the fact "initialization". Now, this stemmed mostly from the context of limited types and I would think it just fine if they alone had these special semantics (as they are treated specially in many places). And it certainly appears to make sense to generalize this to include stack allocations. > Actually, the expression is evaluated first, since it's discriminants or > bounds might determine what to create. Then the object is created. picky! picky! :-) > Fine. All I was saying is that the same arguments apply equally to both > "new T'(...)" and "X: T := ...;". I don't think I disagreed with this. Only tried to point out why the allocator case _seems_ different. > >So, the "not" refers to the fact that with access to class wide types > >the "structure equivalent" semantics _are_ what you get. _One_ named > >type being allowed to refer to whole sets of possible structures. > > Not quite. For named access-to-class-wide types, you get named > equivalence. For anonymous access-to-class-wide types, you get > structural equivalence. And the latter is only allowed in certain > cases (parameters and discriminants). Well, you get named equivalence for the access type. But you do get a "structural equivalence" (modulo the parent) for the designated types. And you get "operational equivalence" with no hitch. You know all this but it is all I meant: type T is tagged ... type T_Ref is access all T'Class; ... procedure Op ( X : access T ); -- or just T ... type C1 is new T... type C2 is new C1 ... type C3 is new T ... procedure Fop ( X : access C3 ); -- or just C3 ... procedure My_Op ( X : T_Ref ) is Ref : T_Ref := new C3; -- -- In here any operation on any descendent of T can be invoked -- on X or Ref, modulo runtime constraints for the current -- specific type of the designated object. And any field of T -- is accessable irrespective of the specific type of the -- designated object. ... Fop(Ref); Op(X); Op(Ref); ... Ref := ... etc. Re: [To _all_ or not to _all_...] > True, but the non-all syntax matches what Ada 83 does, so it was natural > to leave that alone, and add on the "all" syntax meaning "you can do > conversions when you couldn't in Ada 83". Anyway, typing "all" all the > time is a very minor annoyance -- what annoys me more is have two > features in the language, where one would suffice. Ah - the joys of backward compatibility. Not to worry - just imagine how Bjarne must feel! :-) /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com