Re: T'Interface attribute

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2017-08-11 02:33, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> 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