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: Thu, 10 Aug 2017 19:33:56 -0500 Organization: JSA Research & Innovation Message-ID: References: Injection-Date: Fri, 11 Aug 2017 00:33:57 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="29904"; 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:47687 Date: 2017-08-10T19:33:56-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:omh11u$1bto$1@gioia.aioe.org... > On 2017-08-10 01:03, Randy Brukardt wrote: ... >> We were binding Windows (specifically Win32), not creating some abstract >> GUI. Trying to impose typing on an underlying design (especially one as >> complex as Win32) that doesn't have it is almost always a losing game. > > I am not a fan of MFC, yet they tried that. But basically you confirmed my > point, it is either interfaces or low-level and weakly-typed. I don't think they tried it much, there are only a handful of basic callbacks in Win32, and those are presented to all window types. They may have had more synthesized callbacks than we do, but we do have some. They just belong to a single branch of types and are directly implemented by the root type of the branch. (Yes, if some child type overrides the general routine and failed to call the parent routine, the whole thing will fall over in a heap. Not much to do about that in Ada 95.) There just are a number of these derived actions that are commonly used enough that we put them at the top level. That prevents the overriding problem (no one can override the message dispatching loop itself). It doesn't make sense to define, say, When_Horizontal_Scroll, on ten different window types. (Note that using interfaces, you'd *still* have to define the default implementation on all of those window types, and even with multiple inheritance that Ada doesn't have, you'd still have to override the general message routine for each of those window types [multiple inheritance can't combine the differing implementation inherited from different ancestors, that has to be done manually]. So, I don't see that interfaces or even multiple inheritance really buys much here. Randy.