Re: Task interface and entries with aliased parameters

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

"Bob Duff" <bobduff@theworld.com> wrote in message 
news:87lham3hyu.fsf@theworld.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> Sharing interfaces *sounds* nice, but it's impossible in practice because 
>> in
>> almost all circumstances you need parameters of different types for
>> different "instances" ("instances" not in the Ada sense). Think container
>> interfaces, for example - the element type is almost always different.
>
> Different from what?  Maybe you could show some code that illustrates
> your point.

Backing up a bit: an "interface" is just a type and its operations 
(primitive operations in Ada jargon). An interface (Ada term) just gives a 
single name to that set. The problem is, that it is rare that you have more 
than one "interface" in a program (or library, or anything) where the 
operations all have the same parameter profiles.

A container (say a map) is an example. A map interface sounds useful and 
attractive, but it's an illusion. Many of the operations of a map have 
parameters of the element type. And those are likely to be different, 
unrelated types. (Indeed, if your compiler doesn't share generic bodies, 
it's almost guaranteed as you'll want to have all containers with a 
particular element type share an instance in order to avoid code bloat -- in 
which case there would never be a use for an interface.)

The only way for such a map interface to be useful is to have one for some 
related hierarchy of types. But that either forces all the type checking to 
runtime (since the interface can only take Root'Class), or some sort of 
co-derivation scheme (not part of Ada) in order to derive multiple types in 
lock-step. (I've tried to figure out how to make such a scheme work in Ada 
terms, but I've failed; you get weird situations of inherited routines where 
the types don't work out.)

You could also put such an interface into a generic to parameterize the 
different types, but that doesn't buy you anything over using a similar 
generic directly.

I could see how interfaces might make some sense in a language where 
everything is descended from a single type (Object in Java), but Ada is far 
away from that. Thus, I put Ada interfaces with the group of mistaken 
features in Ada: anonymous access types, coextensions, interfaces. I fault 
myself in part for those mistakes, because I didn't recognize how truely 
useless (and even damaging) these things would turn out to be.

                                          Randy.