comp.lang.ada
 help / color / mirror / Atom feed
From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: About 0Y interfaces
Date: Wed, 19 Oct 2005 16:51:21 -0500
Date: 2005-10-19T16:51:21-05:00	[thread overview]
Message-ID: <2cudnQu4z6l6I8veRVn-hA@megapath.net> (raw)
In-Reply-To: sa4irvtlvr3.fsf@snoopy.microcomaustralia.com.au

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

                          Randy.






  reply	other threads:[~2005-10-19 21:51 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-18 12:49 About 0Y interfaces Alex R. Mosteo
2005-10-18 13:18 ` Dmitry A. Kazakov
2005-10-18 14:34   ` Alex R. Mosteo
2005-10-18 16:54     ` Dmitry A. Kazakov
2005-10-18 16:36 ` Pascal Obry
2005-10-18 22:01   ` Randy Brukardt
2005-10-19  9:08     ` Brian May
2005-10-19 21:51       ` Randy Brukardt [this message]
2005-10-20  6:44         ` Alex R. Mosteo
2005-10-19  9:11     ` Pascal Obry
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox