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,f428ff2031155951 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!postnews.google.com!l22g2000pre.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Equivalent of dynamic_cast (downcast) for tagged types Date: Fri, 28 Jan 2011 08:44:08 -0800 (PST) Organization: http://groups.google.com Message-ID: <242e5c66-04cf-46a0-ae33-5f4d70946b51@l22g2000pre.googlegroups.com> References: <375fb596-ab12-4cb0-a190-53d62b94b2e4@e9g2000vbi.googlegroups.com> <510d779c-d15b-4fc1-b831-bfc578ecdb4b@z3g2000prz.googlegroups.com> <7q5flc9of9ey.19h9nmmzjxqn0.dlg@40tude.net> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1296233049 31391 127.0.0.1 (28 Jan 2011 16:44:09 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 28 Jan 2011 16:44:09 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: l22g2000pre.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618; .NET4.0C),gzip(gfe) Xref: g2news2.google.com comp.lang.ada:17745 Date: 2011-01-28T08:44:08-08:00 List-Id: On Jan 28, 1:16=A0am, "Dmitry A. Kazakov" wrote: > On Thu, 27 Jan 2011 14:35:28 -0800 (PST), Maciej Sobczak wrote: > > I have submitted this bug report more than one year ago. Looks like > > nobody even bothered to check it. > > Well, I am not a language lawyer to tell if the behavior (public overridi= ng > of a private primitive operation) is legal. > > > The bug submission states that Adjust is wrongly recognized as > > overriding, which it shouldn't be - but now I have hit something more > > interesting. > > It must be overriding because Adjust is a primitive operation. Wrong. I can't find the language rule right now, but I'm certain that if a tagged type T has a primitive operation Op declared in the private part, and another package declares a type extension of T and declares its own operation Op with the same profile, in a place where the first Op is not visible, then the new Op is a **new** operation that has no connection with the Op in the private part of the first package. This is what I would expect, since the private part of a package isn't supposed to have any semantic effect on places that can't see the private part. Here's an example: package Pak1 is type T1 is tagged null record; procedure Op1 (X : in out T1); procedure Test (Param : in out T1'Class); private procedure Op2 (X : in out T1); end Pak1; with Ada.Text_IO; use Text_IO; package body Pak1 is procedure Op1 (X : in out T1) is begin Put_Line ("in Pak1.Op1"); end Op1; procedure Op2 (X : in out T1) is begin Put_Line ("in Pak1.Op2"); end Op2; procedure Test (Param : in out T1'Class) is begin Op1 (Param); Op2 (Param); end Test; end Pak1; with Pak1; use Pak1; package Pak2 is type T2 is new T1 with null record; --overriding ILLEGAL! procedure Op2 (X : in out T2); end Pak2; with Ada.Text_IO; use Ada.Text_IO; package body Pak2 is procedure Op2 (X : in out T2) is begin Put_Line ("in Pak2.Op2"); end Op2; end Pak2; with Pak1; with Pak2; procedure Test87 is Y : Pak2.T2; begin Pak1.Test (Y); end Test87; The Op2 defined in Pak2 has no connection with the Op2 defined in the private part of Pak1. It is not overriding. And if Pak1.Op2 is called as a dispatching operation, it will **not** dispatch to Pak2.Op2, which is basically a new operation. I compiled this with GNAT and got Pak1.Op1 Pak1.Op2 as expected. (If you comment out the "private" keyword in Pak1, the second line becomes Pak2.Op2.) Furthermore, if the "overriding" line is uncommented, GNAT correctly rejects the declaration, saying the procedure does not override anything. So since it's correctly rejecting the "overriding" in this case, but not rejecting "overriding" on an Adjust operation of a type derived from Limited_Controlled, there's definitely something amiss in the compiler. My guess is that the compiler handles (Limited_)Controlled specially and thus doesn't quite go through the same path that it goes through in my example. But it's definitely a compiler bug, not a portability issue. -- Adam