Re: interfaces and limited/controlled/limited-controlled types

[Jere <jhb.chat@gmail.com>]

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.