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 10.107.163.5 with SMTP id m5mr12406876ioe.101.1517061873549; Sat, 27 Jan 2018 06:04:33 -0800 (PST) X-Received: by 10.157.24.117 with SMTP id t50mr1188251ott.9.1517061873422; Sat, 27 Jan 2018 06:04:33 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!border1.nntp.ams1.giganews.com!nntp.giganews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.am4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!g80no148660itg.0!news-out.google.com!b73ni595ita.0!nntp.google.com!w142no150289ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 27 Jan 2018 06:04:33 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=173.71.208.22; posting-account=QF6XPQoAAABce2NyPxxDAaKdAkN6RgAf NNTP-Posting-Host: 173.71.208.22 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: interfaces and limited/controlled/limited-controlled types From: Jere Injection-Date: Sat, 27 Jan 2018 14:04:33 +0000 Content-Type: text/plain; charset="UTF-8" X-Received-Body-CRC: 3501047255 X-Received-Bytes: 4619 Xref: reader02.eternal-september.org comp.lang.ada:50180 Date: 2018-01-27T06:04:33-08:00 List-Id: On Saturday, January 27, 2018 at 2:12:44 AM UTC-5, Randy Brukardt wrote: > "Alejandro R. Mosteo" wrote in message > ... > > I just was lamenting myself recently for not recalling this idea for the > > next revision. Just add new interfaces with the same semantics. > > That would probably work for Root_Storage_Pool and Root_Streams as these > generally don't have any associated implementation. > > For controlled, however, a common implementation strategy is to build the > overhead into the root type (the chaining components that are common to all > controlled object). Interfaces can't have components, and the work to allow > that in this one case is roughly equivalent to allowing all interfaces to > have components (which of course is full multiple inheritance -- which would > make Dmitry happy :-). I don't see any point in doing a massive amount of > work inside the compiler and not letting users have access to it. So it > essentially is full MI or bust here (and I personally vote for bust :-). > > > I wonder if there are technical problems besides having a duplicated > > feature. > > If there is any concrete implementation associated with the root type, then > an interface is not a useful replacement. You would need multiple > inheritance to work for abstract types (in which case interfaces are a junk > redundant feature). Most likely, existing vendors would just forget about > upgrading their compilers (that seems to be the case for some vendors > anyway, wouldn't want to make it a perfect sweep :-). > > Randy. I didn't see this in the discussion referenced, but how hard is it for the compiler to detect that a specific language defined interface is used and have it do a mixin for the needed components. The mixin would be a hidden part from the compiler. You could break it up into 3 portions: 1. The public controlled interface that clients use 2. A secondary hidden interface that provided the low level operations needed. This would be a descendant of the public one from #1 3. A hidden mixin to hold the needed pointer back to the object and to provide implementations to the hidden interface. It would be a descendant of that hidden interface in #2. The new type being created by a client would be a descendant of this part. Whenever someone used the public controlled interface, the compiler would detect that an insert the intermediate parts under the hood. It might require compiler support as I don't think it could be done in pure standard Ada easily. It wouldn't need to replace the existing controlled tagged types (they could probably just be implementations of the interface for backwards compatibility). NOTE: I know I am being a bit hap-hazard here. This is easier said than done. I'm just wondering if it is possible. Alternately, many other languages have solved this issue in a safe way, so there have to be other means to solve it that are reasonable. I would imagine some compilers are able to detect when an object is going out of scope or when the delete operation is called on a reference and insert the finalization code at those times.