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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,20144c9b38aef82d X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Alex R. Mosteo" Newsgroups: comp.lang.ada Subject: Re: About 0Y interfaces Date: Thu, 20 Oct 2005 08:44:42 +0200 Message-ID: <43573CDA.8060806@mailinator.com> References: <4354EF40.9010906@mailinator.com> <43552495.2050300@obry.net> <2cudnQu4z6l6I8veRVn-hA@megapath.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net HcSryheu9E/vVI7lbcecfAP8NJOTRFHwiFJ8a/sGHNN+CqQL0= User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en In-Reply-To: <2cudnQu4z6l6I8veRVn-hA@megapath.net> Xref: g2news1.google.com comp.lang.ada:5813 Date: 2005-10-20T08:44:42+02:00 List-Id: Randy Brukardt wrote: > "Brian May" wrote in message > news:sa4irvtlvr3.fsf@snoopy.microcomaustralia.com.au... > >>>>>>>"Randy" == Randy Brukardt 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...