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!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: T'Interface attribute Date: Fri, 11 Aug 2017 08:55:57 +0200 Organization: Aioe.org NNTP Server Message-ID: References: NNTP-Posting-Host: MajGvm9MbNtGBKE7r8NgYA.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Language: en-US Xref: news.eternal-september.org comp.lang.ada:47699 Date: 2017-08-11T08:55:57+02:00 List-Id: On 2017-08-11 02:33, Randy Brukardt wrote: > "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]. It could provide hook within the loop. And you would have to call parent's part from the override. This is the case of overriding by an extension. > So, I don't see that interfaces or even multiple inheritance really buys > much here. It adds type safety. It a quite frequent error in GUI design to write a handler for an event that never comes. Then it allows typed arguments in the event handler. In Windows everything is LPARAM, same in Gtk. When using GtkAda it makes a huge difference. GtkAda defines some typed handlers, but not all. When you get hit by necessity to extract marshaled signal arguments and convert them to the designated types manually you thank GtkAda for all cases when you don't have to. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de