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:a24:3344:: with SMTP id k65-v6mr2351828itk.10.1533256983520; Thu, 02 Aug 2018 17:43:03 -0700 (PDT) X-Received: by 2002:aca:75c9:: with SMTP id q192-v6mr166654oic.3.1533256983383; Thu, 02 Aug 2018 17:43:03 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.uzoreto.com!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!g24-v6no1364898iti.0!news-out.google.com!l67-v6ni1119itl.0!nntp.google.com!d7-v6no1346134itj.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 2 Aug 2018 17:43:03 -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: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Visibility of Indexing aspects From: "Dan'l Miller" Injection-Date: Fri, 03 Aug 2018 00:43:03 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:54027 Date: 2018-08-02T17:43:03-07:00 List-Id: On Thursday, August 2, 2018 at 3:31:18 PM UTC-5, Randy Brukardt wrote: > (Sorry about breaking the thread, the reference headers have gotten too l= ong=20 > for the news server to accept them. - RLB) >=20 > "Dan'l Miller" wrote in message > news:ebf25374-fbd0-4239-9f24-1496b7699f74@googlegroups.com... > >On Friday, July 27, 2018 at 5:06:00 PM UTC-5, Randy Brukardt wrote: > >> "Dan'l Miller" wrote in message > >> news:71ab145a-83fd-46af-81c3-fe72c67c6897@googlegroups.com... > >> > ...(even when the programmer considers 4 of them as a bad idea) ... > >> > >> A pretty inflexible programmer if you ask me. This is the same sort of > >> programmer that then complains that the performance of indexing isn't > >> good > > enough, because they are triggering all of this expensive mechanism rat= her > >> than directly doing something simple. > > > >Expensive? Gee, I would think that precisely the same machine code > >verbatim > >would be generated for each of the following syntactic variants of the o= ne > >and > >only same semantic meaning: > > > >Find (IB,"pear").Data.all :=3D Element'(...); -- Traditional call > >IB.Find ("pear").Data.all :=3D Element'(...); -- Call of prefixed view > >IB.Find ("pear") :=3D Element'(...); -- Implicit dereference (see 4.1.5) > >IB ("pear") :=3D Element'(...); -- Implicit indexing and dereference > >IB ("pear").Data.all :=3D Element'(...); -- Implicit indexing only >=20 > Surely, and all 5 of these are quite expensive, because the use of Refere= nce > (which is implicit in all 5 of these!) requires returning (and thus creat= ing > and destroying) a controlled, composite object. [GNAT has a non-standard = way > of eliminating the controlled part, which of course makes the use of the > containers substantially less safe.] >=20 > My point is that a programmer that truly cares about performance (and > hopefully that will only be concerning in a few critical situations) woul= d > avoid using Reference at all if there isn't a need to update-in-place par= t > of the element. That is, one would still use the underlying operations, b= ut > individually rather than all automatically as part of a set. >=20 > Randy. In the above-mentioned case of prohibiting 4 of the 5, the programmer seeks= not performance improvement. The programmer seeks proscribing the retenti= on of certain* data and structure by the outside-of-this-package world=E2= =80=94topics which the outside-of-this-package world has no business retain= ing or using directly or abusing, syntactic sugar notwithstanding, and hist= orical pre-syntactic-sugar idioms notwithstanding. The Steelman 3-5B requi= rement is all about the app-domain designer overtly intentionally proscribi= ng certain* semantics from ever being able to appear in the outside-of-pack= age world. Steelman 3-5B is not about some clever performance tweaking. * The certain semantics to be proscribed outside of the declaring package i= s any form of letting private guts hang out publicly, as some sort of seman= tic hernia. {Reference, Reference_Holder, Container_Array} in OP are all i= ntended to be guts internal within the package's private view's abdominal m= uscle wall, not a semantic hernia gratuitously (mis)placed in the public vi= ew of the package.