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.1 required=5.0 tests=BAYES_00, PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Is this a bug? Date: Fri, 17 Jan 2020 16:14:22 -0600 Organization: JSA Research & Innovation Message-ID: References: <1d96e0e1-7700-4947-9fcb-051a1203c703@googlegroups.com> <8bc80421-29fb-4f19-baf0-b14680a99c32@googlegroups.com> Injection-Date: Fri, 17 Jan 2020 22:14:23 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="7381"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader01.eternal-september.org comp.lang.ada:57864 Date: 2020-01-17T16:14:22-06:00 List-Id: "reinert" wrote in message news:c02eb3b5-68e7-431e-bc3c-74dc278409ed@googlegroups.com... fredag 3. januar 2020 09.37.32 UTC+1 skrev Dmitry A. Kazakov følgende: ..... >> >> Yes, but that is was not possible, because in Ada 95 the function "a" >> did not conflict with members. The change in Ada 2005 introduced dot >> notation and thus the conflict. >Still I struggle to understand this. Why could it not be possible to tell >the compiler >that "this is Ada strict and do not - for god's sake - accept such possible >ambiguities" ? Possible, I suppose, but Ada (to date) does not have error "modes" -- either something is an error or it is not. If something is enough of a problem to reject it, there almost never a sensible And, as previously noted, if A.Component is ambiguous, there is no notation for accessing the component in some other way. So such a component is completely inaccessible - the only choice is to rename it. That's a problem waiting to happen, especially for those working on top of OOP hierarchies where they don't own the root type. If someone adds a conflicting operation, now you're forced to change the component names of all of your code. And this sort of conflict is not that unusual in private types. I have a number of private types where I have a component (in the private part) and a getter function (that's visible) with the same name. There's no conflict with users outside of the package, but an ambiguity would require changing the name of the component. (And such a change itself could be dangerous, as any uses that got missed would silently change to calling the Getter function - a possible problem of infinite recursion or (if the getter does more than just return the value) doing extra uninitended operations. I think an ambiguity rule in a new language with thought-out alternatives probably would be preferable, but it wouldn't work well in Ada. Randy.