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 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Smart pointers and delegation Date: Wed, 2 Aug 2017 22:36:37 -0500 Organization: JSA Research & Innovation Message-ID: References: Injection-Date: Thu, 3 Aug 2017 03:36:39 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="25822"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: news.eternal-september.org comp.lang.ada:47562 Date: 2017-08-02T22:36:37-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:olrqum$1t4b$1@gioia.aioe.org... > On 2017-08-02 01:06, Randy Brukardt wrote: >> "Dmitry A. Kazakov" wrote in message >> news:olplb6$jq0$1@gioia.aioe.org... >>> I would like to discuss delegation proposal as a replacement for crude, >>> inside out Implicit_Dereference aspect. >> >> There never are "replacements", as existing Ada code has to work. > > It is not replacement in that sense. Replacement here applies to the "use > case", i.e. creating subtypes. Implicit dereferencing effectively makes > pointer a "subtype" of the target type. As I noted at the end of my message, your proposal does not replace the "use case" for Implicit_Dereference. So this isn't true. >> And as usual, you didn't explain the problem that you're trying to solve. > > The problem is subtyping and automated creation of wrappers to implement > "trivial" operations. The method is delegation. Examples are presented. I think you need to concentrate on describing that problem rather than any particular solution to solve it. It doesn't seem like a problem that is really solveable in the general case. (Certainly if you want to make some sort of proposal; not so much if you are just making talk here.) ... >> Implicit_Dereference very much matches the Ada model of "hooks" into >> language-defined operations (much like Adjust and Finalize allow >> user-defined operations to be associated with an assignment, rather than >> replacing it). > > ? Not even close. Adjust and Finalize are primitive operations, which was > a horrific design choice, but nevertheless. Implicit dereference is not an > operation, not even a body. In the intended use, Implicit_Dereference is always combined with a controlled type, which provides the actual hooks. As I noted yesterday, the original idea was specifically for explicit hooks (as part of the storage pool mechanism, similar to Adjust and Finalize), but that got replaced when it was pointed out that one could already write the needed support using an access discriminant and associated controlled type. That got rid of the need to define new mechanisms and deal with the inevitable corner cases. The only problem with that was that it was unspeakably ugly, so Implicit_Dereference was created to get rid of that without adding any real new semantics. Any other use of Implicit_Dereference is purely accidental; no other use provides anything that can't be written directly in Ada 95. >> The main intended use of this feature was to manage the lifetime of >> accessed >> entities, such as a persistent store, without requiring copies of the >> contained data (which might be large). > > Copies are very essential in many cases, e.g. an external reference to a > database table row etc. It is up to the programmer to define the > semantics. If you want (or don't care about copies) copies, normal primitive functions work great. See, for instance, function Element in the various containers packages. The access discriminant/controlled type/Implicit_Dereference mechanism is intended for those cases where a copy is not usable (either because of semantics or because of execution cost). >> Your proposal doesn't meet this particular need, because there is no way >> to >> tell when the program is finished with a function result. > > I don't understand what you mean. The proposal considers exclusively how > to generate bodies of normal primitive operations. All current rules apply > to them, no any new rules needed. That's the problem: the Implicit_Dereference mechanism is intended for the rare cases where "normal primitive operations" don't work (because they imply copies for function results). If "normal primitive operations" work, you don't need (and shouldn't use) any special mechanism. >From your description, you're trying to solve an altogether different problem. That's fine, of course, but just don't confuse that with the rather low-level problem that Implicit_Dereference was actually trying to solve. Randy.