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.236.32.229 with SMTP id o65mr16667681yha.19.1374519570468; Mon, 22 Jul 2013 11:59:30 -0700 (PDT) X-Received: by 10.182.129.84 with SMTP id nu20mr403172obb.40.1374519570284; Mon, 22 Jul 2013 11:59:30 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!news.glorb.com!cb17no13801qab.0!news-out.google.com!dk8ni1201qab.0!nntp.google.com!cb17no13795qab.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 22 Jul 2013 11:59:29 -0700 (PDT) In-Reply-To: <79e0bc53-5431-493d-95d1-aac74c7d19c9@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> <79e0bc53-5431-493d-95d1-aac74c7d19c9@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <947d8137-edc1-4abc-92b6-ace9dcec9bbb@googlegroups.com> Subject: Re: orthogonal inheritance and extension aggregates From: Adam Beneschan Injection-Date: Mon, 22 Jul 2013 18:59:30 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:16473 Date: 2013-07-22T11:59:29-07:00 List-Id: OK, I've thought about this a little more. First of all, I think the probl= em might be unique to Ada. Ada allows you to write a generic that takes an= arbitrary tagged type and defines a new extension of that type. The one o= ther OOP language I'm most familiar with, Java, just doesn't allow this: public class ExtensionOf extends T is ... is illegal. (T is a "type variable" which is pretty much the equivalent of= a generic formal tagged type, and "extends" is how you write derived types= ; but "extends" doesn't allow "type variables" in its syntax.) If it did allow it, the new type wouldn't inherit T's constructors, since c= onstructors just aren't inherited. Ada does try to inherit the "constructo= rs", i.e. functions that return values of the type; but of course the inher= ited constructors make no sense because they cannot initialize extension co= mponents. Thus, an inherited constructor (for a concrete type) is illegal= and must be overridden. But, as this example shows, this can't be done wh= en the parent type is a generic formal type, since we don't know what funct= ions might be defined for the actual. =20 It doesn't make sense for the Extension generic package to try to provide v= ersions of all the constructors that might be defined for the actual type. = I think that the "right" way to handle this would be for Extension to defi= ne a function that takes a Parent object and returns an Extended object: function Create_Extended (Obj : Parent) return Extended; where Create_Extended would initialize fields and whatever other action is = necessary, and then the code that uses it would do something like E1 : Extended :=3D Create_Extended (To_Vector (...)); assuming that Extended were not declared "abstract". This doesn't solve th= e legality problem, though. So I'm thinking that the rules in 3.9.3 need to be relaxed. 3.9.3(4-6) say= s that for a derived type, if the parent type has any abstract subprograms = or functions with a controlling result, then (1) if the derived type is abs= tract, the inherited subprogram is abstract; or (2) the subprogram must be = overridden, except in null extension cases. What I'm thinking is that we n= eed a (2a) that says something like: if the parent type is a generic formal= tagged type or type extension, and the derived type is not a generic forma= l, and if the subprogram is not abstract [which means it must be a function= with a controlling result], and if no overriding subprogram is explicitly = provided, the subprogram is overridden with an implicit subprogram that doe= s nothing but raise Program_Error. This should solve the problem in a case= like this--where the language demands that some subprograms be overridden = but does not provide any mechanism for doing so. I'm assuming that if this= were the case, Extended would no longer need to be "abstract". (If it wer= e, this change wouldn't be sufficient.) Any thoughts? Does this seem like a possibly worthwhile proposal? -- Adam=20