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: Tue, 8 Aug 2017 19:27:15 -0500 Organization: JSA Research & Innovation Message-ID: References: Injection-Date: Wed, 9 Aug 2017 00:27:15 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="22351"; 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:47651 Date: 2017-08-08T19:27:15-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:omblk3$svi$1@gioia.aioe.org... > On 2017-08-08 00:39, Randy Brukardt wrote: >> "Dmitry A. Kazakov" wrote in message >> news:om3vsc$jhk$1@gioia.aioe.org... ... >>> Implicit dereferencing semantically does the same. For each visible >>> operation of the target type it declares an anonymous operation of the >>> reference type that dereferences and then calls to the original >>> operation. >> >> I don't see this at all. > > You do it with the eyes closed... (:-)) That's possible. I'm not the best at seeing patterns; I'm much more likely to write everything from scratch. Thus I don't find use for interfaces, for one example. ... >> It's not really opposite, though, if you want to limit the lifetime of >> the >> reference (even if that limit is potentially a long time). > > Why would I want this, if the reference manages the object? The cardinal > difference is between object-managed references and reference-managed > objects. The former has a very limited use and would prefer to have all of > them built-in. In that case, you definitely need to know precisely when the reference dies, so you can "manage the object". If you have a lifetime leak (such as any normal access type does), then you can't do that management safely. The pattern of the intended use-case of Implicit_Dereference does exactly this. Yes, I agree that it would have been better to have an explicit call-back (that was the original idea, after all), but that was a lot more complex in language and implementation terms. I don't think the complex version was going to fly, and the simple version solves the problem that we needed to solve. Sometimes, a "meh" idea that you can actually get implemented is better than a brilliant idea that doesn't get any traction and thus never actually exists anywhere. Randy. Randy.