Re: Interfaces and abstract tagged types

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

On Sun, 05 Oct 2008 16:29:36 -0400, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> (Interfaces was a huge mistake)
> 
> Interesting.  Why do you say so?

Because there already existed abstract types for that. One should simply
have allowed honest multiple inheritance.

The limitation of not having any implementations of primitive operations or
component makes just no sense.

In fact this artificial limitation is extremely damaging. In one running
project, which is Ada 2005, we have huge amounts of code duplication
because of this silly constraint. It massively damages reuse:

   type Read_File is limited interface;
   type Write_File is limited interface;
   type Read_Write_File is limited interface and Read_File and Write_File;
      -- have fun!

It seems that the limitation also provokes abstraction inversion and
"god-classes." I have had no time to investigate the reasons why, but the
effect is noticeable in large projects. Certainly lack of multiple dispatch
plays a role here too.

Further, interfaces produce lots of noise code when the implementation type
and the interface type declarations duplicate each other. The interface
cannot be inherited from a concrete type, so one is forced to invent
interface, pushing it before the type and then inherit from that. This ends
up in a situation when nearly each abstract tagged type is declared as:

   type A_Interface is limited interface;
   procedure Foo (X : A) is abstract;
   type A is abstract ... and A_Interface with ...;
   overriding procedure Foo (X : A);

BTW, this also applies to the standard library. Root_Storage_Pool,
Root_Stream_Type, Limited_Controlled etc must have inheritable interfaces.
Where are they?

The situation is remarkably similar to generics. Same bunch of helper/proxy
things. Permanent search for good names for entities which should not
existed in first place, an exploding number of packages used in order to
keep that rubbish somewhere outside the *code*, which does useful stuff.
That hits you back, when you need to understand why the compiler complains
about something that does not implement do-not-know-where-declared
something, etc.

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