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 X-Received: by 2002:a02:bb01:: with SMTP id y1-v6mr46022jan.35.1532572894145; Wed, 25 Jul 2018 19:41:34 -0700 (PDT) X-Received: by 2002:aca:2b06:: with SMTP id i6-v6mr3516oik.0.1532572893775; Wed, 25 Jul 2018 19:41:33 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.uzoreto.com!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!g2-v6no382577itf.0!news-out.google.com!l67-v6ni134itl.0!nntp.google.com!g2-v6no382573itf.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 25 Jul 2018 19:41:33 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.195.62; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.195.62 References: <40d568da-4715-42de-8e28-98da39a5c974@googlegroups.com> <34f499f7-020f-4dcc-adad-0ab1113386d1@googlegroups.com> <9d69e7b5-6b2d-4607-9f7b-affa78c41620@googlegroups.com> <41c711cb-0300-4a41-93d3-e69297ae1945@googlegroups.com> <42de4aa3-9e7c-44b8-aa84-712cc7ce03c6@googlegroups.com> <9b6b6f10-5956-4a19-83f5-c1c015c62602@googlegroups.com> <8720f70a-59b1-4297-b2fc-78804ec88b7b@googlegroups.com> <756cb66b-1ef8-4d9e-b679-118b6c59e89c@googlegroups.com> <1392b483-af72-4dbe-ad51-bd703405b7a8@googlegroups.com> <3eebe2fb-f066-4248-9b2f-1db32497fd82@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Visibility of Indexing aspects From: "Dan'l Miller" Injection-Date: Thu, 26 Jul 2018 02:41:34 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:53966 Date: 2018-07-25T19:41:33-07:00 List-Id: On Wednesday, July 25, 2018 at 7:12:24 PM UTC-5, Randy Brukardt wrote: > "Dan'l Miller" wrote in message=20 > news:3eebe2fb-f066-4248-9b2f-1db32497fd82@googlegroups.com... > On Wednesday, July 25, 2018 at 2:58:44 PM UTC-5, AdaMagica wrote: > >> Much ado about nothing. > >> > >> The writer of this code erroneously put things in the private part whi= ch > >> should have been public. There is a compiler bug leaking from privacy > >>which seduced the writer into thinking that his wrong code is correct. > >> > >> The RM is very precise about this, see the references in this thread. > >> > >> Love's Labours Lost with any further discussion. > > > >In other words, I made an insightful good point ... >=20 > Sounds like babble to me. What's used by the client has to be public,=20 > period. >=20 > ... > >The _LRM_'s forcing of {Reference, Reference_Holder, Container_Array, ..= .}=20 > >to be public declarations ... >=20 > ...is perfectly fine -- there's nothing wrong or dangerous with using the= m=20 > directly. Indeed, "indexing" is just a shorthand for a longer call involv= ing=20 > Reference -- you're always allowed to make the longer call Yeah, unyieldingly demanding that unnecessary feature is the root-cause of = the violation of Steelman 3-5B detailed far below. In effect as explained in detail far below, Steelman 3-5F is requiring the = ability to optionally have this scenario in addition to _AARM_:2016's =C2= =B622/3 of =C2=A74.1.6 on page 189, by burying {Find, Data} in private view= with only IB and its Variable_Indexing aspect in public view: from outside the package: Find (IB,"pear").Data.all :=3D Element'(...); -- illegal IB.Find ("pear").Data.all :=3D Element'(...); -- illegal IB.Find ("pear") :=3D Element'(...); -- illegal IB ("pear") :=3D Element'(...); -- allowed IB ("pear").Data.all :=3D Element'(...); -- illegal > , just like you=20 > are allowed to put in .all even if you could have omitted it. We went to= =20 > substantial lengths to ensure that you can't keep a reference value longe= r=20 > than the existence of the return object from Reference -- regardless of h= ow=20 > you use the package. (Telling people not to do something is never an=20 > effective technique for safety!) >=20 > If you have declarations that *can't* be used directly, then put them int= o=20 > the private part. But you're never supposed to be getting a half-and-half= =20 > situation. >=20 > Randy. So which part of the definition of =E2=80=9Cdeclaration=E2=80=9D does each = member d of {Reference, Reference_Holder, Container_Array} not satisfy with= respect to Steelman 3-5B's =E2=80=9CIn particular, it shall be possible to= prevent external reference to =E2=80=A2=E2=80=A2any declaration=E2=80=A2= =E2=80=A2 within the encapsulation including automatically defined operatio= ns =E2=80=A6=E2=80=9D? Or is it that each d fails to satisfy the definition= of =E2=80=9Cany=E2=80=9D? Because the only way to satisfy Steelman 3-5B a= nd still have the _LRM_'s current wording hold regarding all of {Variable_I= ndexing aspect, Reference, Reference_Holder, Container_Array} absolutely be= ing in the public view is for somehow someone to demonstrate how Reference = isn't =E2=80=9Cany declaration=E2=80=9D, Reference_Holder isn't =E2=80=9Can= y declaration=E2=80=9D, and Container_Array isn't =E2=80=9Cany declaration= =E2=80=9D. It does quite clearly say =E2=80=9Cany declaration=E2=80=9D there in Steelm= an 3-5B. Indeed, 3-5B even wisely predicts the precise situation of implic= itly/automatically compiler-generated operations (e.g., the Variable_Indexi= ng aspect) in the =E2=80=9Cincluding automatically defined operations=E2=80= =9D. It seems that Steelman 3-5B is overtly requiring the ability to decla= re Variable_Indexing in the public part of the package with {Reference, Ref= erence_Holder, Container_Array} in the private part of the package, due to: 1) Variable_Indexing be 3-5B's =E2=80=9Cincluding automatically-defined ope= rations=E2=80=9D; 2) Reference clearly fully satisfies the definition of 3-5B's =E2=80=9Cany = declaration=E2=80=9D; 3) Reference_Holder clearly fully satisfies the definition of 3-5B's =E2=80= =9Cany declaration=E2=80=9D; 4) Container_Array clearly fully satisfies the definition of 3-5B's =E2=80= =9Cany declaration=E2=80=9D; 5) In the current wording of the _LRM_, =E2=80=9Can encapsulation=E2=80=9D = of {Reference, Reference_Holder, Container_Array} shall =E2=80=A2=E2=80=A2n= ot=E2=80=A2=E2=80=A2 be capable of =E2=80=9Cinhibit[ing] external access to= implement properties of the definition=E2=80=9D of public declaration of t= he Variable_Indexing aspect on the incomplete declaration of Container. Therefore because of the =E2=80=9C=E2=80=A2=E2=80=A2not=E2=80=A2=E2=80=A2 c= apable of=E2=80=9D there, Steelman 3-5B is clearly not satisfied for Contai= ner's Variable_Indexing with respect to declarations of each of {Reference,= Reference_Holder, Container_Array}. Steelman 3-5B grants no exception for =E2=80=98chain migration=E2=80=99 of = one declaration (e.g., public declaration of Variable_Indexing) having the = tenacity to =E2=80=A2pull=E2=80=A2 (or should I say, =E2=80=A2pollute=E2=80= =A2) declarations forcibly from should-have-been private declaration-list i= nto being =E2=80=A2forced=E2=80=A2 public declarations. Indeed, not only d= oes Steelman 3-5B not grant such a chain-migration pulling of declarations = from private to public (or should I say, polluting public view with should-= have-been private declarations), Steelman 3-5B goes the extra mile in precl= uding any exceptions whatsoever, even overtly calling out this very situati= on of automatically generated operations 3 decades ahead of time as not bei= ng an exception to the requirement. It seems that modern Ada's compliance with Steelman 3-5B needs to be downgr= aded from full to partial due to this topic (and perhaps any other yet-to-b= e-discovered aspects' chain-migrations of should-have-been private declarat= ions to forced-public declarations).