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-Thread: 103376,5a88548f1bcf3510 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Received: by 10.66.84.202 with SMTP id b10mr4914499paz.43.1352489097965; Fri, 09 Nov 2012 11:24:57 -0800 (PST) Received: by 10.68.253.129 with SMTP id aa1mr3992277pbd.17.1352489097718; Fri, 09 Nov 2012 11:24:57 -0800 (PST) Path: s9ni1660pbb.0!nntp.google.com!kt20no39705977pbb.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 9 Nov 2012 11:24:57 -0800 (PST) In-Reply-To: <1vej4u29b8e4z$.289wazkl31wg$.dlg@40tude.net> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ NNTP-Posting-Host: 66.126.103.122 References: <1vej4u29b8e4z$.289wazkl31wg$.dlg@40tude.net> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <2592ab84-d216-4a4a-bb77-ca896393aaec@googlegroups.com> Subject: Re: Overring function and its returned type From: Adam Beneschan Injection-Date: Fri, 09 Nov 2012 19:24:57 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-11-09T11:24:57-08:00 List-Id: On Friday, November 9, 2012 12:25:17 AM UTC-8, Dmitry A. Kazakov wrote: > On Fri, 09 Nov 2012 08:13:23 +0100, Yannick Duch=EAne (Hibou57) wrote: >=20 > > overriding > > function F > > (E : T) > > return R'Class -- Not overriding :-( > > is abstract; >=20 > What is this? "overriding" + "abstract" does not make sense. I don't see that. It's true that if you define an abstract type T1 with an= abstract operation Op, and if you derive an abstract type T2 from T1, Op w= ill be inherited, so it doesn't affect the semantics it you redeclare an ab= stract Op. Still, I can certainly understand why a programmer would want t= o redeclare Op anyway, so that a person reading the package that defines T2= will see all the operations available for T2, and won't have to hunt for t= he definition of T1 to see what other operations might be defined for T2. = And if the programmer does redeclare Op for T2, then it's a good idea to ad= d the "overriding" keyword to prevent accidents. Also, it's legal to declare an abstract type derived from a non-abstract ty= pe. In that case, you may actually want to override the non-abstract inher= ited operation with an abstract one. -- Adam >=20 >=20 > In any case it is the default. When you do nothing, you get F through >=20 > inheritance and it is abstract when the parent's F was. >=20 >=20 >=20 > Ada's declarations are not idempotent, in the sense that you cannot repea= t >=20 > them like you could in C++. So "F ... is abstract" always >=20 > overloads/conflicts. >=20 >=20 >=20 > P.S. They should really have used the syntax with the keyword "overriding= " >=20 > trailing behind "is" rather than preceding "function/procedure." >=20 >=20 >=20 > --=20 >=20 > Regards, >=20 > Dmitry A. Kazakov >=20 > http://www.dmitry-kazakov.de