From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-65-14.ec2.internal X-Spam-Level: * X-Spam-Status: No, score=1.6 required=3.0 tests=BAYES_00,PDS_FROM_2_EMAILS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Received: by 2002:a37:a843:0:b0:6c3:3902:a346 with SMTP id r64-20020a37a843000000b006c33902a346mr9097676qke.538.1662367999916; Mon, 05 Sep 2022 01:53:19 -0700 (PDT) X-Received: by 2002:a81:a108:0:b0:345:1ba8:638f with SMTP id y8-20020a81a108000000b003451ba8638fmr6450719ywg.422.1662367999667; Mon, 05 Sep 2022 01:53:19 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!border-1.nntp.ord.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 5 Sep 2022 01:53:19 -0700 (PDT) In-Reply-To: Injection-Info: google-groups.googlegroups.com; posting-host=155.210.248.194; posting-account=SuyozQoAAADXnDELfODTBs7QDv_fdf87 NNTP-Posting-Host: 155.210.248.194 References: <67b32db0-c4db-466c-ac13-e597e008c762n@googlegroups.com> <401d6f59-2c28-4dd5-9fa6-fccf33b6d645n@googlegroups.com> <12cc33b1-2c39-4057-8a03-623064b06e8en@googlegroups.com> <672e9bc6-1e53-42cb-a339-9230ab949de9n@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <6d7f82cf-a52a-4fbe-b9f7-f06e55e76429n@googlegroups.com> Subject: Re: Calling inherited primitive operations in Ada From: "amo...@unizar.es" Injection-Date: Mon, 05 Sep 2022 08:53:19 +0000 Content-Type: text/plain; charset="UTF-8" Xref: reader01.eternal-september.org comp.lang.ada:64290 List-Id: On Saturday, September 3, 2022 at 2:01:32 AM UTC+2, Randy Brukardt wrote: > "amo...@unizar.es" wrote in message > news:672e9bc6-1e53-42cb...@googlegroups.com... > On Thursday, September 1, 2022 at 11:33:47 PM UTC+2, Jeffrey R.Carter wrote: > > On 2022-09-01 20:54, Emmanuel Briot wrote: > > >> As presented, this seems very over complicated. Elements and > >> Definite_Elements > >> add no value, and this is just a complex way of writing > > >Going in a tangent, and I guess you know perfectly well, but this is caused > >by the > >painful duplication of code that Ada pushes you to by not having a native > >way to > >abstract storage of definite vs indefinite types. > This is premature optimization at it's worst. Just because the language doesn't offer a way to do it. Otherwise I wouldn't need to care. > > So the provider of a generic library very soon faces this conundrum about > > duplicating most interfaces, if not implementations, or resort to > > non-trivial > > generics, or accept an unnecessary penalty for definite types, or push to > > the client the definite storage matter. > There is no penalty in a code sharing implementation like Janus/Ada: the > implementation of definite types is essentially the same as you would write > by hand for an indefinite type. In most cases, all one needs is an > indefinite generic. Well, that sounds neat for Janus/Ada, but is a different issue to clients having to wrap their indefinite types prior to instantiation, and suffer the unwrapping throughout the code. > (The plan for Janus/Ada was always to use post-compilation optimization to > reduce the overhead of generics, but admittedly, that part never got built. > If I had infinite time...) > > Assuming otherwise is certainly premature optimization. I'm of the opinion that it goes beyond just premature optimization, in the terrain of readability/maintainability by causing boilerplate, and when generics specializations do become necessary, by causing code duplication. > > There's simply no satisfying solution here [that I know of]. The > > duplication of > > every standard container to have both [in]definite variants is a strong > > indictment. > The original expectation for the containers was that there would be many > variants of each container, because the needs for memory management, task > management, and persistence differ between applications: there is no > one-size fits all solution. > > But I agree on one point: the "basic" container is unncessary; one should > either use the indefinite or bounded container (depending on your memory > management needs, either fully fixed or fully heap-based) -- stopping in the > middle makes little sense. That makes sense, right. > > Randy.