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!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Smart pointers and delegation Date: Thu, 3 Aug 2017 09:40:06 +0200 Organization: Aioe.org NNTP Server Message-ID: References: NNTP-Posting-Host: MajGvm9MbNtGBKE7r8NgYA.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:47572 Date: 2017-08-03T09:40:06+02:00 List-Id: On 2017-08-03 05:36, Randy Brukardt wrote: > "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.) I have no illusions (:-)) So talk would be just fine. Especially if in the end the concept catches interest. Delegation is a very powerful mechanism which requires very little if any language tampering. It is a very nice alternative for generics which does not generate a whole second language tier unreadable and unmaintainable. >>> 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. ? These are not hooks on the operation of dereferencing. [E.g. you cannot make a task-safe dereferencing by taking a lock at the beginning and releasing it at the end, i.e. a typical Ref/Unref pair] [...] >>> 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. I must and I need it, because in real-life examples (e.g. #1) it is many thousands lines of noise code in both package declarations and bodies. Which is quite error-prone too. > 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. Yes it is a wider problem, but one use-case is exactly same. The solution is different: 1. Dereference: type Target_Interface is interface; type Reference (Pointer : access Target_Interface) is null record with Implicit_Dereference => Pointer; 2. Delegation: type Target_Interface is interface; type Reference is new Target_Interface record Pointer : access Target_Interface'Class end record with Delegate => Pointer; Delegation has no magic whatsoever. It could be done by an ASIS-aware preprocessor actually. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de