interfaces and limited/controlled/limited-controlled types

interfaces and limited/controlled/limited-controlled types

[Mehdi Saada]

Is it only because of history and compatibility issues, that Limited_Controlled and Controlled aren't rewrote as interfaces ?
Like: T_type is limited new Ancestor_type with Controlled 
or T_type is new Ancestor_type with Limited_Controlled

Or is there a semantic issue too ?  

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

[Robert Eachus]

On Thursday, January 25, 2018 at 11:21:11 AM UTC-5, Mehdi Saada wrote:
> Is it only because of history and compatibility issues, that Limited_Controlled and Controlled aren't rewrote as interfaces ?
> Like: T_type is limited new Ancestor_type with Controlled 
> or T_type is new Ancestor_type with Limited_Controlled
> 
> Or is there a semantic issue too ?

There is "stuff" in the private part and body of these packages, which needs to be inherited by all controlled types.  It is sort of irrelevant whether these package bodies (and private parts) can be written in "pure" Ada.  These packages have been around since before Ada 83, when Ada compilers were not written in Ada anyway, and interfaces did not exist.

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

[Randy Brukardt]

"Mehdi Saada" <00120260a@gmail.com> wrote in message 
news:ea190839-2f83-4dbb-9064-8d6f535cc1d0@googlegroups.com...
> Is it only because of history and compatibility issues, that 
> Limited_Controlled and Controlled aren't rewrote as interfaces ?
> Like: T_type is limited new Ancestor_type with Controlled
> or T_type is new Ancestor_type with Limited_Controlled
>
> Or is there a semantic issue too ?

A compatibility issue IS a semantic issue! Yes, the main reason is 
compatibilty. We've looked at ways to allow Root_Streams_Type to be an 
interface (same problem), and the levels of semantic trouble that occurs 
makes it a dubious proposition (at least so far). The issue is still open: 
AI12-0023-1, but it hasn't been worked on since 2012, so I wouldn't hold out 
much hope that anything will happen here. The last meeting notes discuss 
some of the problems involved 
(http://www.ada-auth.org/ai-files/minutes/min-1206.html#AI023).

                                      Randy.

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

[Dmitry A. Kazakov]

On 26/01/2018 05:58, Randy Brukardt wrote:
> "Mehdi Saada" <00120260a@gmail.com> wrote in message
> news:ea190839-2f83-4dbb-9064-8d6f535cc1d0@googlegroups.com...
>> Is it only because of history and compatibility issues, that
>> Limited_Controlled and Controlled aren't rewrote as interfaces ?
>> Like: T_type is limited new Ancestor_type with Controlled
>> or T_type is new Ancestor_type with Limited_Controlled
>>
>> Or is there a semantic issue too ?
> 
> A compatibility issue IS a semantic issue! Yes, the main reason is
> compatibilty. We've looked at ways to allow Root_Streams_Type to be an
> interface (same problem), and the levels of semantic trouble that occurs
> makes it a dubious proposition (at least so far).

Stream and pool interfaces are simpler I suppose than having a 
controlled interface. However having an ability to add finalization 
later would be an indispensable feature. Existing workarounds are not 
good at all.

BTW, was it considered to add new interfaces without making existing 
base types members of? It would not look clean but it would be 100% 
compatible:

    type <anonymous> is interface;
    procedure Initialize (Object : in out <anonymous>) is abstract;
    procedure Adjust     (Object : in out <anonymous>) is abstract;
    procedure Finalize   (Object : in out <anonymous>) is abstract;

    type Controlled is abstract new <anonymous> with private;
    overriding procedure Initialize (Object : in out Controlled) is null;
    overriding procedure Adjust     (Object : in out Controlled) is null;
    overriding procedure Finalize   (Object : in out Controlled) is null;

    type Controlled_Interface is new <anonymous>;

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Alejandro R. Mosteo]

On 26/01/18 09:28, Dmitry A. Kazakov wrote:
> On 26/01/2018 05:58, Randy Brukardt wrote:
>> "Mehdi Saada" <00120260a@gmail.com> wrote in message
>> news:ea190839-2f83-4dbb-9064-8d6f535cc1d0@googlegroups.com...
>>> (...)

> However having an ability to add finalization 
> later would be an indispensable feature. Existing workarounds are not 
> good at all.

Agreed.

> BTW, was it considered to add new interfaces without making existing 
> base types members of? 

I just was lamenting myself recently for not recalling this idea for the 
next revision. Just add new interfaces with the same semantics.

I wonder if there are technical problems besides having a duplicated 
feature.

-Alex.

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

[Randy Brukardt]

"Alejandro R. Mosteo" <alejandro@mosteo.com> wrote in message 
news:p4f2oa$c4u$1@dont-email.me...
...
> 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.

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

[Jere]

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.

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

[Dmitry A. Kazakov]

On 2018-01-27 15:04, Jere wrote:

> 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.

Which is called "multiple inheritance", implementation of (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Jere]

On Saturday, January 27, 2018 at 9:38:46 AM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-01-27 15:04, Jere wrote:
> 
> > 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.
> 
> Which is called "multiple inheritance", implementation of (:-))
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

While you can get some of the effect of MI that way, it is a single
inheritance tree, so not quite the same as MI.  You don't run into
the diamond problem for one.

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

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:p4i2ti$nqp$1@gioia.aioe.org...
> On 2018-01-27 15:04, Jere wrote:
>
>> 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.
>
> Which is called "multiple inheritance", implementation of (:-))

Precisely my point. You would have to implement complete multiple 
inheritance for this one case. It's certainly possible (languages that have 
full multiple inheritance exist, after all), but once you've done that, you 
might as well support it for all types (there isn't a lot of difference).

You might be able to get a bit of simplification by not having to worry 
about discriminant-dependent components or controlled components inside of 
controlled type, but that wouldn't help a whole lot.

                                   Randy.

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

[Randy Brukardt]

"Jere" <jhb.chat@gmail.com> wrote in message 
news:79b4f018-889d-4948-b2d6-ba5506e1ce9c@googlegroups.com...
> On Saturday, January 27, 2018 at 9:38:46 AM UTC-5, Dmitry A. Kazakov 
> wrote:
>> On 2018-01-27 15:04, Jere wrote:
...
> While you can get some of the effect of MI that way, it is a single
> inheritance tree, so not quite the same as MI.  You don't run into
> the diamond problem for one.

Ada already has rules for that - if you've implemented interfaces (I 
haven't), that's handled. It's the inheritance of components that causes all 
of the implementation problems. And it doesn't matter much what those 
components are, the effort is roughly the same.

                              Randy.

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

[Alejandro R. Mosteo]

On 27/01/18 08:12, Randy Brukardt wrote:
> "Alejandro R. Mosteo" <alejandro@mosteo.com> wrote in message
> news:p4f2oa$c4u$1@dont-email.me...
> ...
>> 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 understand now, thanks. I had considered the user side POV only, 
thinking that some "compiler magic" would be involved, but certainly 
didn't suspect it would be so big a change.

Thanks,
Alex.

> 
>> 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.
> 
>