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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!reality.xs3.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Non_Primitive Operations and Object.Operation Resolution Date: Fri, 22 Apr 2016 17:24:26 -0500 Organization: JSA Research & Innovation Message-ID: References: NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1461363866 27943 24.196.82.226 (22 Apr 2016 22:24:26 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 22 Apr 2016 22:24:26 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:30248 Date: 2016-04-22T17:24:26-05:00 List-Id: "Jeffrey R. Carter" wrote in message news:nfbfj0$1m2$1@dont-email.me... > On 04/21/2016 01:28 PM, Randy Brukardt wrote: ... >> If you would like, I could take this to the ARG and see if anyone has any >> insight. > > That would probably be a good idea. Subtypes are not types and I'd think > should not be considered an ancestor of the type. Considering a subtype as > an ancestor seems like it would be a disaster. I've sent the question to the ARG. But I don't see any "disaster" even if the subtype is included; there shouldn't be routines with the same name and profile sitting around to get picked up anyway. >> In any case, your code is unnecessarily fragile, as even if GNAT is wrong >> in >> this particular instance, future program maintenance could make the GNAT >> behavior correct. I'd suggest giving the non-primitive Element a >> different >> name -- less convinient, perhaps, but if you do that you don't have visit >> grey areas in the RM. :-) > > Perhaps. Element seemed the best name at the time, given my limited > understanding of the language. My view is that anytime you have more than one visible (note: not necessarily *directly* visible) entity with the same name and same profile, but has different semantics, you have unnecessarily tricky code, regardless of the legality of that code. A reader of the code could very well refer to the wrong declaration (programmers are not great at figuring out the nuances of Ada visibility rules), and that could lead to problems during program maintance (especially if that maintenance is done by someone other than the original author). As such, I'd suggest that the routine in the body be named something like Safe_Element just to reduce this potential confusion. (I know *I* could very well use the wrong routine in debugging this package.) Still, legal Ada code ought to compile. even when it isn't a good idea. :-) Randy.