Re: T'Interface attribute

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:om3ta9$fnc$1@gioia.aioe.org...
...
> There is nothing wrong with additive inheritance. The same interface when 
> added twice once publicly once privately could simply allocate new slots.

We tried that. But...

>...  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. And 
having calls be illegal in such cases is a massive problem in generic 
bodies. Typical assume-the-worst rules would have to make calling any 
interface related to a formal illegal in a generic body.

It was a massive can of worms.

The alternative approach (the interface is the same) breaks privacy pretty 
badly.

We essentially gave up, and more recent attempts to allow a limited set of 
"hidable interfaces" didn't fare any better.

...

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

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

The other hierarchies (canvas, menus, etc.) work similarly.

                                       Randy.