Interfaces and abstract tagged types

Interfaces and abstract tagged types

[Dale Stanbrough]

Hi,

I was wondering what the magical incantation is to have an abtract 
tagged null record (or abstract tagged private) also implement an 
Interface.

I've tried various combinations reserved words, all without much luck!

Dale

-- 
dstanbro@spam.o.matic.bigpond.net.au

Re: Interfaces and abstract tagged types

[Dmitry A. Kazakov]

On Sun, 05 Oct 2008 07:01:31 GMT, Dale Stanbrough wrote:

> I was wondering what the magical incantation is to have an abtract 
> tagged null record (or abstract tagged private) also implement an 
> Interface.
> 
> I've tried various combinations reserved words, all without much luck!

   type X is limited interface;
   type Y is abstract tagged null record;
   type Z is abstract new Y and X with null record;

(Interfaces was a huge mistake)

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

Re: Interfaces and abstract tagged types

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sun, 05 Oct 2008 07:01:31 GMT, Dale Stanbrough wrote:
>
>> I was wondering what the magical incantation is to have an abtract 
>> tagged null record (or abstract tagged private) also implement an 
>> Interface.
>> 
>> I've tried various combinations reserved words, all without much luck!
>
>    type X is limited interface;
>    type Y is abstract tagged null record;
>    type Z is abstract new Y and X with null record;

Yes, or:

    type A is limited interface;
    type B is new A with null record;

> (Interfaces was a huge mistake)

Interesting.  Why do you say so?

- Bob

Re: Interfaces and abstract tagged types

[Dmitry A. Kazakov]

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

Re: Interfaces and abstract tagged types

[Ivan Levashew]

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

I'm wondering why nobody has replied yet.

I think it to be a known thing. Interfaces are by definition
implementation-less. A bindable implementation of interface is called
adaptor. In Ada 2005, adaptors are mapped to generic mix-ins.

See Case 2 here:
http://www.adaic.org/learn/tech/multin.html

The only difference with Ada 2005 is that mix-ins were unable to be
adaptors in Ada 95 (there was no interfaces).

Re: Interfaces and abstract tagged types

[Dmitry A. Kazakov]

On Thu, 16 Oct 2008 00:51:53 -0700 (PDT), Ivan Levashew wrote:

>>>> (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.
> 
> I'm wondering why nobody has replied yet.

Maybe, because I am right? (:-))

> I think it to be a known thing. Interfaces are by definition
> implementation-less.

Yep, a bankrupt bank is known to be money-less... An  implementation-less
program may sound funny, alas it turns into reality. As I described in my
previous post, we have a growing amount of code that is just noise.

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

Re: Interfaces and abstract tagged types

[Ivan Levashew]

> Maybe, because I am right? (:-))

As for me, it's because it takes much time to get how to use every of
3 cases.

> reality. As I described in my
> previous post, we have a growing amount of code
> that is just noise.

>   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);

A code duplication ratio is expected to be
between 2:1 and 3:1. Is it noise? Did your team
use generic mix-ins?

Re: Interfaces and abstract tagged types

[Dmitry A. Kazakov]

On Thu, 16 Oct 2008 02:23:46 -0700 (PDT), Ivan Levashew wrote:

>> Maybe, because I am right? (:-))
> 
> As for me, it's because it takes much time to get how to use every of
> 3 cases.

These 3 cases represent an implementation view on inheritance. As such this
classification contradicts to the fundamental concept of separation
interfaces and implementations. If an implementation choice (the case
number) forces you to change the interface, then the language design is
broken. With all respect to Tucker Taft, the text you refer to is merely an
excuse for a language design fault.

>> reality. As I described in my
>> previous post, we have a growing amount of code
>> that is just noise.
> 
>>   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);
> 
> A code duplication ratio is expected to be
> between 2:1 and 3:1. Is it noise?

Yes, per definition: a thing without semantic meaning is noise.

> Did your team use generic mix-ins?

Yes. You need to move implementations down the inheritance tree, because
upper nodes are interfaces:

  A <-- B1..BN <-- C1..CM

This multiplies the same code by the factor of W**D where W is the tree
width and D is the tree depth.

In order to handle this exponentially exploding code, generics are
introduced down the tree. I.e. Bi becomes a generic and interfaces are
passed as formal parameters of. Then the generic instances are passed down
the tree to lower generics. You get the idea...

The perversion is that inheritance as form of polymorphism is technically
replaced by another form of (parametric polymorphism). What are interfaces
for, if generics must be used instead?

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

Re: Interfaces and abstract tagged types

[Georg Bauhaus]

Dmitry A. Kazakov schrieb:

> The perversion is that inheritance as form of polymorphism is technically
> replaced by another form of (parametric polymorphism). What are interfaces
> for, 

For the JNI and similar?

Re: Interfaces and abstract tagged types

[Dmitry A. Kazakov]

On Thu, 16 Oct 2008 12:27:08 +0200, Georg Bauhaus wrote:

> Dmitry A. Kazakov schrieb:
> 
>> The perversion is that inheritance as form of polymorphism is technically
>> replaced by another form of (parametric polymorphism). What are interfaces
>> for, 
> 
> For the JNI and similar?

What does this have to do with Ada?

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

Re: Interfaces and abstract tagged types

[Georg Bauhaus]

Dmitry A. Kazakov schrieb:
> On Thu, 16 Oct 2008 12:27:08 +0200, Georg Bauhaus wrote:
> 
>> Dmitry A. Kazakov schrieb:
>>
>>> The perversion is that inheritance as form of polymorphism is technically
>>> replaced by another form of (parametric polymorphism). What are interfaces
>>> for, 
>> For the JNI and similar?
> 
> What does this have to do with Ada?

$$$ and mixed language programming.

Re: Interfaces and abstract tagged types

[Dmitry A. Kazakov]

On Thu, 16 Oct 2008 15:35:52 +0200, Georg Bauhaus wrote:

> Dmitry A. Kazakov schrieb:
>> On Thu, 16 Oct 2008 12:27:08 +0200, Georg Bauhaus wrote:
>> 
>>> Dmitry A. Kazakov schrieb:
>>>
>>>> The perversion is that inheritance as form of polymorphism is technically
>>>> replaced by another form of (parametric polymorphism). What are interfaces
>>>> for, 
>>> For the JNI and similar?
>> 
>> What does this have to do with Ada?
> 
> $$$ and mixed language programming.

I still do not understand. What is wrong with RM B.1 and how this can be
related to an inability to inherit an operation?

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

Re: Interfaces and abstract tagged types

[Ivan Levashew]

> For the JNI and similar?

Unlikely. CORBA mapping works fine without interfaces.

Some notes on the subject itself:

Usually, interfaces should be preferred. But sometimes there are cases
where different objects must closely interact, and they explicitly
must have a common internal represenation.

Consider 2 examples:

1. You have a set of objects. This set is internally sorted somehow.
You'd like to have a "&"(Left, Right : Set_Type) operation. Although
it's pretty possible to compose an universal merge implementation
being able to inefficiently merge vendor A's set and vendor B's set,
one would like to use efficient merges. In this case, Left and Right
must have something in common, that is, be an descendants of abstract
tagged type instead of interface.

2. Another case is sockets. There is a "select()" procedure in Sockets
API. Let's assume that there are several finite state machines
operating on sockets streams. Vendor A's FSM and vector B's FSM must
have a common internals in order to be able to be used in a "select()"
call. Once again, abstract tagged type is preferred over interface
here.

There's a bad option to define "anti-interface" exposing desired
internals, e. g. socket handle. Don't do like this.

---------------------

> The perversion is that inheritance as form of polymorphism is
> technically
> replaced by another form of (parametric polymorphism). What are
> interfaces for, if generics must be used instead?

Interfaces are for run-time polymorphism, the final goal.
Generics is just an aid to do it in a handy way.

> In order to handle this exponentially exploding code,
> generics are
> introduced down the tree. I.e. Bi becomes a generic and
> interfaces are
> passed as formal parameters of. Then the generic instances
> are passed down
> the tree to lower generics.

Right, it is supposed to be used this way. Maybe your complaints are
due to lack of good UML tools for Ada 2005?

> The interface
> cannot be inherited from a concrete type

I think this is obvious that Ada designer can't let you do this
trick. A concrete type might have more primitive operation than
interface you're want to declare. List and Vector have extra
operations that can be done efficiently. How can Ada compiler be sure
whether you'd like to treat Vector implementation as an implementation
of hypothethic Vector_Interface or whether Vector is just an
enumerable container. If it's really the case that every primitive
operation must be copied to the interface, this fact must be stated
explicitly.

Re: Interfaces and abstract tagged types

[Dmitry A. Kazakov]

On Wed, 22 Oct 2008 23:39:10 -0700 (PDT), Ivan Levashew wrote:

>> The perversion is that inheritance as form of polymorphism is
>> technically
>> replaced by another form of (parametric polymorphism). What are
>> interfaces for, if generics must be used instead?
> 
> Interfaces are for run-time polymorphism, the final goal.
> Generics is just an aid to do it in a handy way.

Oh, certainly pulling a car with horses is an aid, but I prefer its
engine...
 
>> In order to handle this exponentially exploding code,
>> generics are
>> introduced down the tree. I.e. Bi becomes a generic and
>> interfaces are
>> passed as formal parameters of. Then the generic instances
>> are passed down
>> the tree to lower generics.
> 
> Right, it is supposed to be used this way. Maybe your complaints are
> due to lack of good UML tools for Ada 2005?

One meta language (generics) is far than enough to make it unmaintainable.
You suggest that yet another layer put on top the pile should help?

Anyway, I don't like the idea that Ada interfaces where introduced just in
order to support sells of UML tools... (:-))

>> The interface
>> cannot be inherited from a concrete type
> 
> I think this is obvious that Ada designer can't let you do this
> trick. A concrete type might have more primitive operation than
> interface you're want to declare.

This is a software design issue, not compiler's business. Do not inherit if
you prefer cut-and-paste.

> List and Vector have extra
> operations that can be done efficiently. How can Ada compiler be sure
> whether you'd like to treat Vector implementation as an implementation
> of hypothethic Vector_Interface or whether Vector is just an
> enumerable container. If it's really the case that every primitive
> operation must be copied to the interface, this fact must be stated
> explicitly.

I don't understand the problem. Clearly, when you inherit, you do
everything visible. Same happens when you inherit interface from interface,
why does not it bother you then?

There exist separate issues of disallowing operations and/or delegation.
Neither is possible in Ada, but these are unrelated to interfaces. 

----------
Basically, there should be no language concept "interface." It is
fundamentally wrong, because it reveals something about the implementation
(that no one shall exist).

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