Re: About 0Y interfaces

["Alex R. Mosteo" <devnull@mailinator.com>]

Randy Brukardt wrote:
> "Brian May" <bam@snoopy.apana.org.au> wrote in message
> news:sa4irvtlvr3.fsf@snoopy.microcomaustralia.com.au...
> 
>>>>>>>"Randy" == Randy Brukardt <randy@rrsoftware.com> writes:
>>
>>    Randy> Personally, I find implementation inheritance to be more
>>    Randy> useful than interface inheritance, but obviously others
>>    Randy> feel differently. And, in any case, interfaces allow using
>>    Randy> OOP with tasks and protected types, which wasn't a
>>    Randy> possibility in Ada 95.
>>
>>How?
>>
>>(yes... ok... my imagination is limited tonight...)
> 
> 
> Task types and protected types can inherit from interfaces. There are rules
> for matching operations declared in those types with the primitive
> operations of the interfaces (it's called "implemented by..."). And of
> course, all of the OOP things work on Interface'Class. In addition,
> dispatching procedure calls can be used as an entry in timed and conditional
> entry calls, and ATC. This gives the effect of dispatching entry calls
> without having to have such a construct.
> 
> In addition, there are specific kinds of interfaces (task interfaces,
> protected interfaces, synchronized interfaces [for which the implementation
> must be a task or protected type]); they guarentee that the concrete type is
> the right kind of thing.Task interfaces can be used as a task (in an abort
> statement, the prefix of 'Completed and 'Terminated, and in the task id
> package).
> 
> What you can't do is derive from a task or protected type that has an
> interface. That is, there is no implementation inheritance, only interface
> inheritance. We had looked at ways to provide implementation inheritance for
> protected types, but they suffered from real problems of composition. We
> eventually concluded that interface inheritance works fine, and it is quite
> useful by itself, so that's what was provided. The advantage of avoiding any
> implementation inheritance is that all of the locking code for a PT is
> located in one place -- so analyzing its correctness (and applying
> optimizations) can be done simply by reading the code (no hidden magic).
> Determining that a PT has the correct behavior is quite difficult without
> any inheritance; it would be nearly intractable with it.
> 
> How long it will be before compilers provide all of this is another
> question. I suspect that it will be a fairly low priority for many
> implementers.

I already implemented an interface using tasks and protected types with 
Gnat GAP. I was quite surprised that it worked already...