Re: Interfaces

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

"Florian Weimer" <fw@deneb.enyo.de> wrote in message
news:87zmutsenr.fsf@deneb.enyo.de...
...
> > Anyway, I thought you were worried about the case where T implements J1
> > and J2, both of which have type-conformant Foo's.  And you override them
> > separately.  Then it's clear which one you dispatch to from J1'Class
> > and J2'Class.  But if you have an object X of type T, which overriding
> > does Foo(X) call?
>
> My knee-jerk reaction is: require a type conversion in all cases.
> Probably unacceptable if you want to compete with Java. 8->

Interfaces are a weird beast, rather different from the other sort of types
in Ada. They really have a fairly global scope, and even more interesting,
the number of times or the place that you inherit them doesn't have any
effect on their semantics.

Because of that, they are only usable when there is no chance of needing
more than one implementation. (For instance, sorting would be a bad use for
an interface, because you may want to sort the same type in more than one
way. But you can't do that with interfaces.)

Similarly, the operations need to have well-defined semantics. And if
multiple interfaces have the same operation; it is the *same* operation.
Essentially, all of the operations of all of the interfaces in a program are
a global grouping -- *you* have to keep the names separate.

Because of these issues, I find interfaces to be a concept with very limited
utility. They're mostly useful for things that otherwise wouldn't have any
way to share code (such as tasks or protected objects with different
implementations). I just wasn't going to win the fight to keep them out of
Ada 2006.

(Of course, in 5 years someone will stick this note in my face when I'm
advocating some sort of interface programming. I'm prepared. :-)

                                          Randy Brukardt.