From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: Is this a bug?
Date: Fri, 17 Jan 2020 16:14:22 -0600
Date: 2020-01-17T16:14:22-06:00 [thread overview]
Message-ID: <qvtbju$76l$1@franka.jacob-sparre.dk> (raw)
In-Reply-To: c02eb3b5-68e7-431e-bc3c-74dc278409ed@googlegroups.com
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2000 bytes --]
"reinert" <reinkor@gmail.com> 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.
next prev parent reply other threads:[~2020-01-17 22:14 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-30 15:44 Is this a bug? reinert
2019-12-30 17:51 ` Anh Vo
2019-12-30 18:41 ` Niklas Holsti
2019-12-30 19:50 ` reinert
2019-12-30 20:11 ` Dmitry A. Kazakov
2019-12-30 23:16 ` Randy Brukardt
2019-12-31 19:40 ` Optikos
2019-12-31 21:50 ` Randy Brukardt
2020-01-02 9:34 ` Dmitry A. Kazakov
2020-01-03 7:26 ` reinert
2020-01-03 7:35 ` reinert
2020-01-03 8:37 ` Dmitry A. Kazakov
2020-01-04 0:42 ` Randy Brukardt
2020-01-05 13:32 ` reinert
2020-01-06 10:43 ` J-P. Rosen
2020-01-06 12:19 ` Tero Koskinen
2020-01-17 9:54 ` reinert
2020-01-17 10:08 ` Dmitry A. Kazakov
2020-01-17 22:14 ` Randy Brukardt [this message]
2019-12-31 6:08 ` J-P. Rosen
-- strict thread matches above, loose matches on Subject: below --
2004-09-23 0:52 Wojtek Narczynski
2004-09-23 8:35 ` Wojtek Narczynski
2004-09-23 14:52 ` Nick Roberts
2004-09-23 22:26 ` Brian May
2004-09-24 0:28 ` Stephen Leake
2004-09-24 0:57 ` Jeffrey Carter
2004-09-24 12:47 ` Wojtek Narczynski
2004-09-25 0:17 ` Brian May
2004-09-24 12:37 ` Wojtek Narczynski
2004-09-23 11:27 ` Jeff C r e e.m
2004-09-24 0:30 ` Stephen Leake
2004-09-24 1:49 ` Jeff C r e e.m
2004-09-25 12:59 ` Stephen Leake
2004-10-04 16:36 ` Warren W. Gay VE3WWG
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox