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: a07f3367d7,f428ff2031155951 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!postnews.google.com!n2g2000pre.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 09:33:49 -0800 (PST) Organization: http://groups.google.com Message-ID: References: <375fb596-ab12-4cb0-a190-53d62b94b2e4@e9g2000vbi.googlegroups.com> <510d779c-d15b-4fc1-b831-bfc578ecdb4b@z3g2000prz.googlegroups.com> <7q5flc9of9ey.19h9nmmzjxqn0.dlg@40tude.net> <242e5c66-04cf-46a0-ae33-5f4d70946b51@l22g2000pre.googlegroups.com> 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 1296236029 26184 127.0.0.1 (28 Jan 2011 17:33:49 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 28 Jan 2011 17:33:49 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: n2g2000pre.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:17748 Date: 2011-01-28T09:33:49-08:00 List-Id: On Jan 28, 8:44=A0am, Adam Beneschan wrote: > > 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. =A0This > 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. Some clarifications: (1) The above doesn't apply if the "another package" is a child package. Thus, in my example, if you change Pak2 to Pak1.Pak2, that changes the result, because the Op2 in Pak1.Pak2 does override an inherited operation that is implicitly declared in the private part of Pak1.Pak2 (even though the private part of Pak1.Pak2 is itself implicit; it's still there). But when the package is not a child package, the inherited operation is not declared at all, so there's no overriding. (2) I think the language rules involved are around 3.9.2(20ff); AARM 3.9.2(20.a.3/3) seems to be the most important explanation in this case. See also AI05-126. -- Adam