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 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: T'Interface attribute Date: Tue, 8 Aug 2017 19:38:09 -0500 Organization: JSA Research & Innovation Message-ID: References: Injection-Date: Wed, 9 Aug 2017 00:38:09 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="22580"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: news.eternal-september.org comp.lang.ada:47652 Date: 2017-08-08T19:38:09-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:ombkql$rjr$1@gioia.aioe.org... > On 2017-08-08 00:59, Randy Brukardt wrote: >> "Dmitry A. Kazakov" wrote in message > >>> ... In all contexts where both become visible must require explicit >>> name >>> resolution, e.g. by renaming one of the types and/or primitive >>> operations. >> >> Ada doesn't have type renaming, so this is not possible in general. > > Not exactly renaming, but a schema to qualify the parent: > > type T is new I as I1 and new I as I2 with null record; > overriding I1 procedure Foo (X : T); > overriding I2 procedure Foo (X : T); This sort of thing is *precisely* what we mean when we talk about "type renaming". Renaming has to bring along the primitives. Sadly, we've never been able to work out a version that isn't evil (the effect of the simple version is as nasty as a package use clause, and less obvious, so it tends not to fly). >>>> I've generally materialized that as "the root of an abstraction should >>>> always be declared abstract". >>> >>> Yes, but this is not enough, because it kills potential >>> multiple-inheritance cases. >> >> As an implementer, knowing that multiple-inheritance is just barely >> possible >> to implement, I'm unwilling to consider that unless no other possibility >> exists. And some other way always exists. :-) > > But Ada 2005 did it, so I am happily using it. (:-)) Well, I only use the parts of Ada implemented in Janus/Ada, and interfaces aren't there. (Indeed, the majority of Ada 2005 isn't there, I've kinda skipped ahead to Ada 2012 which is more interesting and implementable.) >>>> In Claw, the only places that we got much benefit from OOP (beyond >>>> dispatching callbacks, the reason we used OOP in the first place) was >>>> in >>>> sharing implementations across related types. But that doesn't work for >>>> Ada >>>> interfaces, because you can't have any components in the type -- >>>> meaning >>>> that writing real implementations is impossible. One can use abstract >>>> types >>>> in this way (and we did so extensively). >>> >>> Reuse happens on the client's side, when you share interface-wide >>> implementations. This includes helper types which refer to [access] >>> I'Class. Surely you have lots of them to pass widgets around, in events, >>> in handlers etc. >> >> Not really. The implementation has such things, but we only exposed >> parameters of Root_Window_Type'Class (with a couple of exceptions). The >> vast >> majority of routines only take a single object. > > If you have a On_Button_Click event handler you want to pass there only > implementations from Window_Clickable_Type'Class. Not just any > Root_Window_Type'Class. And there is no way to place all they subclasses > into single chain of inheritance. Some of Window_Clickable_Type are also > Window_File_Selector_Type and Window_DnD_Type etc. We didn't bother. My recollection is that Windows doesn't make a distinction anyway, I believe all Windows "windows" can be clicked, just some have default actions in that case, and others do nothing. So you can use the handler on any item that has focus, and if you wanted to do something when someone clicked a text label, you could. That allows building new kinds of controls out of existing ones, among other things. In the long run, it because fairly obvious that the best design was to make everything primitive and never use class-wide items anywhere (and only use dispatching in call-backs). Places where we didn't do that we often lived to regret and in extreme cases, change (like the Move Window routine, which started out class-wide and ended up both -- as we couldn't remove the class-wide routine for compatibility reasons). Randy.