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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a24:52c5:: with SMTP id d188mr902337itb.130.1553253022676; Fri, 22 Mar 2019 04:10:22 -0700 (PDT) X-Received: by 2002:a9d:7246:: with SMTP id a6mr6006288otk.246.1553253022404; Fri, 22 Mar 2019 04:10:22 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.166.215.MISMATCH!78no103131itl.0!news-out.google.com!l81ni138itl.0!nntp.google.com!78no103128itl.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 22 Mar 2019 04:10:22 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=70.109.61.2; posting-account=QF6XPQoAAABce2NyPxxDAaKdAkN6RgAf NNTP-Posting-Host: 70.109.61.2 References: <6e1977a5-701e-4b4f-a937-a1b89d9127f0@googlegroups.com> <6f9ea847-2903-48c8-9afc-930201f2765a@googlegroups.com> <94a74b21-9c35-4f90-90f8-6262cde49e20@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <0e27ab0a-5daa-45b0-ae5c-a2441fb1ad40@googlegroups.com> Subject: Re: Intervention needed? From: Jere Injection-Date: Fri, 22 Mar 2019 11:10:22 +0000 Content-Type: text/plain; charset="UTF-8" Xref: reader01.eternal-september.org comp.lang.ada:55929 Date: 2019-03-22T04:10:22-07:00 List-Id: On Thursday, March 21, 2019 at 10:00:41 PM UTC-4, Randy Brukardt wrote: > "Jere" wrote in message > ... > > You would think that a container of limited types would be very > > restrictive, > > but with the advent of Implicit_Dereference and reference types, there > > is definitely some meat there. I would say maps and lists are the two > > areas I find the most need. > > A container of a limited type would be very restrictive. ;-) > > Several of us (including me) have tried to imagine how a container of > limited objects would work, but it just doesn't make much sense. The primary > problem is that one cannot control the lifetime of objects in a container, > which includes the problem that one can't control the initialization of > objects in a container. Whereas for non-limited objects, one just replaces > them with the right data, you can't do that for a limited object. And since > the initialization needs are type-dependent, there's no good way to deal > with it in a type-safe manner. (A constructor with an unknown set of > parameters isn't going to be type-safe, and with any particular set of > parameters is too limiting. > Yes constructors pose a problem. The way I work around it is similar to how Generic_Dispatching_Constructors does. I let them define a parameter which could be a record of parameters. That said, it usually doesn't matter for limited types. When I have had to make and use containers of limited types, I am in one of two places: 1. The limited type was only made limited because of a component or two so the designer created a copy procedure. This lets me mostly treat limited types the same as non limited types. I've literally taken a GNAT container, added a copy procedure formal to the generic, and integrated it into the business logic whereever the compiler told me it couldn't copy a limited type. So far that has worked flawlessly, but I don't know if the customer has tried all of the various functions in the containers. This is the less likely case however. 2. I don't worry about integrating initialization. I just have the container create a default object, and then I can use the combination of cursors and references (or simply a "for of" loop) and initialize them after adding them. So yes, definitely more restrictive than a non limited type container. I just meant the restrictions were not as insurmountable as I have seen in discussions before. This is the more often case. This doesn't 100% cover all remaining cases (like ones where you have to initialize the object at creation), but it has been the remaining 95% solution and very effective. In one case I created a package with the same operations as the customer's but implemented the logic as an Ordered_Map of limited types instead of the array logic they were using, and it increased their through put by 3x (they did a lot of manual searching). It also happened to get a couple of their own programmers to rethink on how they perceived Ada to be an "old" language (very pervasive thought where I work). They had no idea that you could even make iterators in Ada. A couple didn't even know you could do dynamic dispatching as they started in Ada83 and never grew past that.