comp.lang.ada
 help / color / mirror / Atom feed
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: T'Interface attribute
Date: Tue, 8 Aug 2017 08:13:41 +0200
Date: 2017-08-08T08:13:41+02:00	[thread overview]
Message-ID: <ombkql$rjr$1@gioia.aioe.org> (raw)
In-Reply-To: omarcp$rlq$1@franka.jacob-sparre.dk

On 2017-08-08 00:59, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> 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);

>>> 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. (:-))

>>> 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.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de


  reply	other threads:[~2017-08-08  6:13 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-02 13:43 T'Interface attribute Dmitry A. Kazakov
2017-08-02 14:23 ` Eryndlia Mavourneen
2017-08-03 12:52   ` Dmitry A. Kazakov
2017-08-03  4:46 ` Randy Brukardt
2017-08-03  7:26   ` Dmitry A. Kazakov
2017-08-04 23:51     ` Randy Brukardt
2017-08-05  7:49       ` Dmitry A. Kazakov
2017-08-07 22:59         ` Randy Brukardt
2017-08-08  6:13           ` Dmitry A. Kazakov [this message]
2017-08-09  0:38             ` Randy Brukardt
2017-08-09  7:06               ` Dmitry A. Kazakov
2017-08-09 23:03                 ` Randy Brukardt
2017-08-10  7:13                   ` Dmitry A. Kazakov
2017-08-11  0:33                     ` Randy Brukardt
2017-08-11  6:55                       ` Dmitry A. Kazakov
2017-08-11 20:49                         ` Randy Brukardt
2017-08-03 17:27   ` Eryndlia Mavourneen
2017-08-05  0:09     ` Randy Brukardt
2017-08-05 19:02       ` Eryndlia Mavourneen
2017-08-07 22:49         ` Randy Brukardt
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox