Re: Calling inherited primitive operations in Ada

["amo...@unizar.es" <amosteo@unizar.es>]

On Saturday, September 3, 2022 at 2:01:32 AM UTC+2, Randy Brukardt wrote:
> "amo...@unizar.es" <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.