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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.224.36.15 with SMTP id r15mr39919191qad.8.1374508948218; Mon, 22 Jul 2013 09:02:28 -0700 (PDT) X-Received: by 10.50.62.103 with SMTP id x7mr2453826igr.16.1374508948170; Mon, 22 Jul 2013 09:02:28 -0700 (PDT) Path: border1.nntp.ams3.giganews.com!border1.nntp.ams2.giganews.com!border3.nntp.ams.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!xlned.com!feeder5.xlned.com!news.glorb.com!gh1no82093qab.0!news-out.google.com!dk8ni1022qab.0!nntp.google.com!f1no419229qae.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 22 Jul 2013 09:02:27 -0700 (PDT) In-Reply-To: <6995bf02-6143-4d0f-aeb3-89a94bc1ac01@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=66.126.103.122; posting-account=RxNzCgoAAACA5KmgtFQuaU-WaH7rjnAO NNTP-Posting-Host: 66.126.103.122 References: <6995bf02-6143-4d0f-aeb3-89a94bc1ac01@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <79e0bc53-5431-493d-95d1-aac74c7d19c9@googlegroups.com> Subject: Re: orthogonal inheritance and extension aggregates From: Adam Beneschan Injection-Date: Mon, 22 Jul 2013 16:02:28 +0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Original-Bytes: 6441 Xref: number.nntp.dca.giganews.com comp.lang.ada:182626 Date: 2013-07-22T09:02:27-07:00 List-Id: On Friday, July 19, 2013 11:00:34 AM UTC-7, Adam Beneschan wrote: > On Friday, July 19, 2013 10:46:38 AM UTC-7, Felix Krause wrote: >=20 > > I try to implement some feature via orthogonal inhertance like this: >=20 >=20 > > generic > > type Parent (<>) is abstract tagged private; > > package Extension is > > type Extended is abstract new Parent with private; > >=20 > > -- operations of the extended type here > > private > > type Extended is abstract new Parent with record > > -- =85 > > end record; > > end Extension; >=20 > >=20 >=20 > > Now for testing, I tried to apply this on a Vector: >=20 > > package Int_Vectors is new Ada.Container.Vectors (Natural, Integer)= ; > > package Base is new Extension (Int_Vectors.Vector); >=20 > > type Child is new Base.Extended with null record; >=20 > > At the declaration of Child, GNAT tells me "type must be declared=20 > > abstract or "To_Vector" overridden". Can someone explain why this=20 > > happens? As I understand it, To_Vector should be automatically defined= =20 > > for the derived type. Is this because the intermediate type Extended is= =20 > > declared abstract? Or because To_Vector dispatches in the return type? >=20 > This looks like a GNAT bug to me. OK, I goofed. I forgot that the rules were different when it comes to inhe= rited functions that return tagged types. GNAT's error message wasn't real= ly helpful.=20 The more I look at it, the more I think this is a missing language feature = that is not going to be easy to fix. Normally, if you have a tagged type T= and an operation that is a function F that returns T, and in some other pa= ckage P2 you defined a tagged type T2 that is derived from T and adds compo= nents to it, you *must* provide an overriding function F that operates on T= 2 and (presumably) sets up those additional fields. If the language allowe= d you to simply inherit F, that version of F wouldn't set up the new fields= . If you declare T2 to be abstract, the language will let you get away with n= ot overriding F; the inherited F will then be abstract. I think this might= have been a mistake (that is, I think 3.9.3(5) should have applied only to= abstract subprograms, not to functions that return controlling types, at l= east when the parent type is non-abstract). The package that declares the = new fields in the type (i.e. P2) should be responsible for defining the ope= rations that set up the new fields. This is especially the case when the e= xtension fields are declared in a private part, since other packages that d= efine concrete derived types from T2 have no way to set up the extension fi= elds defined for T2 (unless they happen to be in child packages of P2). =20 Generics with formal derived types just make everything worse, as you've no= ticed, because now, at the time the generic is declared, the compiler can't= tell what functions might be present that return the tagged type. When th= e generic is instantiated, the question needs to be asked, "All right, we'v= e just inherited some To_Vector functions that return this new Extended typ= e; who's going to be responsible for making sure the new fields are set up"= ? And you have two packages pointing fingers at each other. Extension say= s it can't do it, because it doesn't know what functions will get inherited= . And the package that contains the instantiation can't do it, because it = can't see the fields that need to be set up. Even if Extension were a publ= ic extension, it still wouldn't work, because the language doesn't provide = a way for code to instantiate a generic and then define new overriding prim= itives *inside* the generic. But in the present case, where it's a private= extension, any solution would have to involve some kind of new and interes= ting kind of cooperation between the two packages, since neither one has ac= cess to all the needed information. The only solution I can think of is to= add some sort of "default extension initializer" feature that Extension co= uld provide, and then the inherited To_Vector functions that call the paren= t To_Vector and then the "default extension initializer" could be implicitl= y defined. But I don't like this, since a single routine that initializes = the extension components in the same way for all functions may not be appro= priate. So basically I think what you're trying to do just shouldn't be done in Ada= , and frankly I think the generic instantiation should have been illegal, a= nd it's a language hole that it lets you get through. I'll try to think ab= out it and see if there's some other solution that better reflects the clas= s of problem you're trying to solve, rather than being a hack to work aroun= d the rules. (Plus I'll try to think about how this might be handled in ot= her languages, although no other language has the same kind of generic feat= ures as Ada so it might be difficult to find an exact parallel.) -- Adam =20