Interfaces

Interfaces

[Florian Weimer]

Suppose there are two interface types, J1 and J2, and the following
dispatching subprogramms:

  procedure Foo (Obj : J1);
  procedure Foo (Obj : J2;

T implements both J1 and J2, and provides a body for

  procedure Foo (Obj : T);

As far as I understand the Ada 200x spec, this subprogram declaration
overrides both versions of Foo, such that

  Foo ((J1 (T_Obj));
  Foo ((J2 (T_Obj));

invoke the same subprogram.  Is this correct?

I don't think this is a desirable approach because it makes interfaces
a strictly non-modular concept, and might force library designers to
add unique prefixes to interface subprogram names.

Re: Interfaces

[Georg Bauhaus]

Florian Weimer wrote:

> As far as I understand the Ada 200x spec, this subprogram declaration
> overrides both versions of Foo, such that
> 
>   Foo ((J1 (T_Obj));
>   Foo ((J2 (T_Obj));
> 
> invoke the same subprogram.

IIUC, if J1 and J2 are interface types, then J1's Foo and J2's Foo
can only be abstract subprograms or null subprograms. If null
procedures, maybe they would be semantically the same anyway,
in a library.

Re: Interfaces

[Florian Weimer]

* Georg Bauhaus:

> Florian Weimer wrote:
>
>> As far as I understand the Ada 200x spec, this subprogram declaration
>> overrides both versions of Foo, such that
>>   Foo ((J1 (T_Obj));
>>   Foo ((J2 (T_Obj));
>> invoke the same subprogram.
>
> IIUC, if J1 and J2 are interface types, then J1's Foo and J2's Foo
> can only be abstract subprograms or null subprograms. If null
> procedures, maybe they would be semantically the same anyway,
> in a library.

Sorry, maybe I should have expressed my thoughts more clearly.
Library 1 provides a Do_Something procedure like:

  procedure Do_Something (Obj : in out J1; Param : String);

Do_Something invokes Foo on Obj.

Library 2 provides a completely different procedure, say
Do_Another_Thing, which also invokes Foo:

  procedure Do_Another_Thing (Obj : J2; Result : out Natural);

T wants to implement both J1 and J2, but can only provide a single
implementation for Foo, which cannot suit both J1 and J2.

Re: Interfaces

[Robert A Duff]

Florian Weimer <fw@deneb.enyo.de> writes:

> Suppose there are two interface types, J1 and J2, and the following
> dispatching subprogramms:
> 
>   procedure Foo (Obj : J1);
>   procedure Foo (Obj : J2;
> 
> T implements both J1 and J2, and provides a body for
> 
>   procedure Foo (Obj : T);
> 
> As far as I understand the Ada 200x spec, this subprogram declaration
> overrides both versions of Foo, such that
> 
>   Foo ((J1 (T_Obj));
>   Foo ((J2 (T_Obj));
> 
> invoke the same subprogram.  Is this correct?

I believe so.

> I don't think this is a desirable approach because it makes interfaces
> a strictly non-modular concept, and might force library designers to
> add unique prefixes to interface subprogram names.

Perhaps.

If you override a procedure, you need to obey the comments on the
original declaration, which specify what it is supposed to (or allowed
to) do.  If you override two things at once, you have to obey two
(possibly different) contracts.  If you find you can't do that,
you've got a name clash.  The usual way to fix it is to change one of
the names.

If you choose descriptive names (not "Foo" ;-)) name clashes will be
rare.

If those two Foo's came from two separate third-partly libraries, then
it can be painful or impossible to change the name.  Various workarounds
are possible.  Look at Eiffel for one possible solution to this
problem.  It's pretty complicated, and could cause some confusion
(for example, Bar overrides Foo, because somewhere in the chain of
derivations somebody renamed Foo to Bar).

I was at an ARG meeting a while ago where this name-conflict problem was
discussed.  At first, I advocated solving it (perhaps with an
Eiffel-like solution, perhaps some other solution).  One response was
that we should solve this problem if and when Ada becomes so popular
that there are zillions of libraries causing name conflicts.  ;-)
But the main argument against solving this problem is that it would
introduce a huge amount of complexity to solve a fairly rare problem.
I was pretty-much convinced by that.

Ada's interfaces were modeled primarily after Java's interfaces, by the
way.

- Bob

Re: Interfaces

[Florian Weimer]

* Robert A. Duff:

> But the main argument against solving this problem is that it would
> introduce a huge amount of complexity to solve a fairly rare problem.
> I was pretty-much convinced by that.

Maybe it wouldn't be too complicated to add a way to specify the
interface which you are overriding? Something like "overriding J1
procedure Foo"?  This would result in an error message if Foo also
overrode a subprogram inherited from T or J2.

> Ada's interfaces were modeled primarily after Java's interfaces, by the
> way.

I wasn't sure, after reading the Java language specification, if Java
interfaces had the same problem. 8->

Re: Interfaces

[Robert A Duff]

Florian Weimer <fw@deneb.enyo.de> writes:

> * Robert A. Duff:
> 
> > But the main argument against solving this problem is that it would
> > introduce a huge amount of complexity to solve a fairly rare problem.
> > I was pretty-much convinced by that.
> 
> Maybe it wouldn't be too complicated to add a way to specify the
> interface which you are overriding? Something like "overriding J1
> procedure Foo"?  This would result in an error message if Foo also
> overrode a subprogram inherited from T or J2.

Maybe.  I'm not sure how this would work with multiple inheritance in
general.  For example the diamond inheritance pattern.

> > Ada's interfaces were modeled primarily after Java's interfaces, by the
> > way.
> 
> I wasn't sure, after reading the Java language specification, if Java
> interfaces had the same problem. 8->

I think it's the same, but I'm not entirely sure -- I haven't looked at
the Java specs in a while.

- Bob

Re: Interfaces

[Florian Weimer]

* Robert A. Duff:

>> Maybe it wouldn't be too complicated to add a way to specify the
>> interface which you are overriding? Something like "overriding J1
>> procedure Foo"?  This would result in an error message if Foo also
>> overrode a subprogram inherited from T or J2.
>
> Maybe.  I'm not sure how this would work with multiple inheritance in
> general.  For example the diamond inheritance pattern.

I'm not after such fancy things.  Basically, I'd like to declare that
there is no diamond, by explicitly labeling the interfaces I'm
overriding.

The compiler has to gather the information anyway, to built the
dispatch tables.  Implementation-wise, it shouldn't be very hard to
check if the subprogram ends up in the specified tables only.

Re: Interfaces

[Vinzent 'Gadget' Hoefler]

Florian Weimer wrote:

> I wasn't sure, after reading the Java language specification, if Java
> interfaces had the same problem. 8->

They do.


Vinzent.

-- 
worst case: The wrong assumption there actually is one.

Re: Interfaces

[Florian Weimer]

* Vinzent Hoefler:

> Florian Weimer wrote:
>
>> I wasn't sure, after reading the Java language specification, if Java
>> interfaces had the same problem. 8->
>
> They do.

And this behavior doesn't cause problems in practice?  Of course, this
would be a rather strong indicator that no additional complexity is
necessary. 8-)

Re: Interfaces

[Vinzent 'Gadget' Hoefler]

Florian Weimer wrote:

> * Vinzent Hoefler:
> 
>> Florian Weimer wrote:
>>
>>> I wasn't sure, after reading the Java language specification, if
>>> Java interfaces had the same problem. 8->
>>
>> They do.
> 
> And this behavior doesn't cause problems in practice?  Of course, this
> would be a rather strong indicator that no additional complexity is
> necessary. 8-)

Well, the idea behind this is: If you implement two interfaces which
share methods with the same name (and signature), you most likely wanted
to implement only one of these methods anyway, so there actually is
only one, no matter how many interfaces share this method.

I'm not sure if I agree with that particular view point "there can be
only one", but that's what an 10-year Java-Professional was paid to
tell us ;-> and it seems like a clever trick to avoid the problems you
would get otherwise.

Ok, some code to make the point more clear:

interface Int_A {
   void Foo();
   void Bar();
}

interface Int_B {
   void Foo();
   void Baz();
}

class One implements Int_A, Int_B {
   void Foo() { ... }; // required from either Int_A or Int_B
   void Bar() { ... }; // required from Int_A
   void Baz() { ... }; // required from Int_B
}

Ok, so far so good. Now the "tricky" part:

class Two implements Int_A {
   void Foo() { ... }; // Int_A
   void Bar() { ... }; // Int_B
}

class Three extends Two implements Int_B {
   void Foo(); // surprise! already implemented by "A.Foo()"!
               // so this is an override of "Two.Foo()"
   void Baz(); // required from Int_B
}

So in this case "class Three" actually only needs to implement "Baz()"
from "Int_B", because "Foo()" was already implemented by "Int_A".

I don't know if Ada interfaces are supposed to have the same behaviour,
but if they do, this doesn't seem much of a problem, since the Java
community seems to be quite satisfied with the solution. Or perhaps
they just don't know better. :->


Vinzent.

-- 
worst case: The wrong assumption there actually is one.

Re: Interfaces

[Pascal Obry]

Hyman Rosen <hyrosen@mail.com> writes:

> Notice that in both cases attempting to refer to Both::i would cause
> compilation

Sorry but I can't notice anything, this is just unreadable, I can't parse all
those () and {}  I must be tired :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Interfaces

[Pascal Obry]

Hyman Rosen <hyrosen@mail.com> writes:

> OK, here it is in pidgin Ada-C++-ish.

Thanks, I can parse that ! And I understood what you meant, isn't language
issues important :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Interfaces

[Florian Weimer]

* Pascal Obry:

> Hyman Rosen <hyrosen@mail.com> writes:
>
>> OK, here it is in pidgin Ada-C++-ish.
>
> Thanks, I can parse that ! And I understood what you meant, isn't language
> issues important :)

What are you talking about?  Unfortunately, Hyman's messages don't
make it to comp.lang.ada, it seems. 8-(

Re: Interfaces

[Georg Bauhaus]

Florian Weimer wrote:

> What are you talking about?  Unfortunately, Hyman's messages don't
> make it to comp.lang.ada, it seems. 8-(

FWIW, the References: entry is cut off after @, before >.

Re: Interfaces

[Dmitry A. Kazakov]

On Mon, 16 May 2005 21:27:37 +0200, Florian Weimer wrote:

> Maybe it wouldn't be too complicated to add a way to specify the
> interface which you are overriding?

That must be done in all cases, even for inheritance from concrete types,
IMO! That would save a lot of grey hairs.

> Something like "overriding J1
> procedure Foo"?  This would result in an error message if Foo also
> overrode a subprogram inherited from T or J2.

That alone would not help much. Consider you have overridden J1.Foo and
J2.Foo using different implementations, then which one will be called on
Foo (X)? Renaming is the only visible way I think.

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

Re: Interfaces

[Florian Weimer]

* Dmitry A. Kazakov:

>> Something like "overriding J1
>> procedure Foo"?  This would result in an error message if Foo also
>> overrode a subprogram inherited from T or J2.
>
> That alone would not help much. Consider you have overridden J1.Foo and
> J2.Foo using different implementations, then which one will be called on
> Foo (X)?

How would this be possible in the single-inheritance-with-interfaces
model?

Re: Interfaces

[Dmitry A. Kazakov]

On Tue, 17 May 2005 11:06:42 +0200, Florian Weimer wrote:

> * Dmitry A. Kazakov:
> 
>>> Something like "overriding J1
>>> procedure Foo"?  This would result in an error message if Foo also
>>> overrode a subprogram inherited from T or J2.
>>
>> That alone would not help much. Consider you have overridden J1.Foo and
>> J2.Foo using different implementations, then which one will be called on
>> Foo (X)?
> 
> How would this be possible in the single-inheritance-with-interfaces
> model?

There cannot be any feasible single inheritance / multiple interface model.
Any inheritance is either single or multiple. Implementation vs. interface
inheritance is an orthogonal issue.

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

Re: Interfaces

[Florian Weimer]

* Dmitry A. Kazakov:

>>> That alone would not help much. Consider you have overridden J1.Foo and
>>> J2.Foo using different implementations, then which one will be called on
>>> Foo (X)?
>> 
>> How would this be possible in the single-inheritance-with-interfaces
>> model?
>
> There cannot be any feasible single inheritance / multiple interface model.
> Any inheritance is either single or multiple. Implementation vs. interface
> inheritance is an orthogonal issue.

That's why I don't understand your question.  The condition is always
false, isn't it?

Re: Interfaces

[Dmitry A. Kazakov]

On Tue, 17 May 2005 12:57:51 +0200, Florian Weimer wrote:

> * Dmitry A. Kazakov:
> 
>>>> That alone would not help much. Consider you have overridden J1.Foo and
>>>> J2.Foo using different implementations, then which one will be called on
>>>> Foo (X)?
>>> 
>>> How would this be possible in the single-inheritance-with-interfaces
>>> model?
>>
>> There cannot be any feasible single inheritance / multiple interface model.
>> Any inheritance is either single or multiple. Implementation vs. interface
>> inheritance is an orthogonal issue.
> 
> That's why I don't understand your question.  The condition is always
> false, isn't it?

Not in every context! In the context of a class-wide method of J1 it is
unambiguous. Or else, consider T that implements J1 publicly and J2
privately.

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

Re: Interfaces

[Robert A Duff]

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

> On Tue, 17 May 2005 12:57:51 +0200, Florian Weimer wrote:
> 
> > * Dmitry A. Kazakov:
> > 
> >>>> That alone would not help much. Consider you have overridden J1.Foo and
> >>>> J2.Foo using different implementations, then which one will be called on
> >>>> Foo (X)?
> >>> 
> >>> How would this be possible in the single-inheritance-with-interfaces
> >>> model?
> >>
> >> There cannot be any feasible single inheritance / multiple interface model.
> >> Any inheritance is either single or multiple. Implementation vs. interface
> >> inheritance is an orthogonal issue.
> > 
> > That's why I don't understand your question.  The condition is always
> > false, isn't it?
> 
> Not in every context! In the context of a class-wide method of J1 it is
> unambiguous. Or else, consider T that implements J1 publicly and J2
> privately.

I believe that's illegal.  You're not allowed to privately implement an
interface.

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?  The Eiffel solution is to rename one of them.
Another solution would be to have some hierarchical notation for saying
"call the Foo that originally came from J1".

- Bob

Re: Interfaces

[Florian Weimer]

* Robert A. Duff:

>> 
>> Not in every context! In the context of a class-wide method of J1 it is
>> unambiguous. Or else, consider T that implements J1 publicly and J2
>> privately.
>
> I believe that's illegal.  You're not allowed to privately implement an
> interface.

I think so, and there's even an AARM note that seems to describe this
particular case.

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

Re: Interfaces

[Randy Brukardt]

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

Re: Interfaces

[Marius Amado Alves]

On 18 May 2005, at 00:21, Randy Brukardt wrote:
> ... I just wasn't going to win the fight to keep interface types out of
> Ada 2006.

I know what you mean. I was one of the very few voicing against them, 
specially pointing to J.-P. Rosen's outstanding article in Ada-Europe 
that shows how Ada 95 already 'does' interfaces, but nobody seemed to 
listen, so I shut up after a cry or two.

/* Interface types for Ada 2006 must be one of the most spectacular 
wastes of energy in the history of language standardisation. Javasing 
Ada, eek! But this is surely my anti-OOP daemons talking. I gave up on 
tagged types long ago. Give me generics anytime. */

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

Me too :-)

Re: Interfaces

[Dmitry A. Kazakov]

On Tue, 17 May 2005 18:21:12 -0500, Randy Brukardt wrote:

> Because of these issues, I find interfaces to be a concept with very limited
> utility.

Poorly implemented MI cannot have much utility.

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

Re: Interfaces

[adam]

Florian Weimer wrote:
> Suppose there are two interface types, J1 and J2, and the following
> dispatching subprogramms:
>
>   procedure Foo (Obj : J1);
>   procedure Foo (Obj : J2;
>
> T implements both J1 and J2, and provides a body for
>
>   procedure Foo (Obj : T);
>
> As far as I understand the Ada 200x spec, this subprogram declaration
> overrides both versions of Foo, such that
>
>   Foo ((J1 (T_Obj));
>   Foo ((J2 (T_Obj));
>
> invoke the same subprogram.  Is this correct?

Unless I've missed something, the above two statements aren't
dispatching calls, so I don't think the overriding subprogram provided
for T would be called.  Maybe this is more in line with what you're
thinking of?

    Foo ((J1'Class (T_Obj));
    Foo ((J2'Class (T_Obj));

                                   -- Adam

Re: Interfaces

[Matthew Heaney]

Florian Weimer <fw@deneb.enyo.de> writes:

> Suppose there are two interface types, J1 and J2, and the following
> dispatching subprogramms:
> 
>   procedure Foo (Obj : J1);
>   procedure Foo (Obj : J2);

This is no different from COM, for example:

   interface I1 : IUnknown { /* ... */ };
   interface I2 : IUnknown { /* ... */ };

Now both I1 and I2 have QueryInterface, AddRef, etc.


> T implements both J1 and J2, and provides a body for
> 
>   procedure Foo (Obj : T);

This is no different from a class that inherits from both I1 and I2:

  class C : public I1, public I2 
  {
  public:
     HRESULT QueryInterface(...);
     //...
  };

The operation QueryInterface is inherited from both I1 and I2.

 
> As far as I understand the Ada 200x spec, this subprogram declaration
> overrides both versions of Foo, such that
> 
>   Foo ((J1 (T_Obj));
>   Foo ((J2 (T_Obj));
> 
> invoke the same subprogram.  Is this correct?

This is no different from saying:

   void f(C& obj)
   {
      const HRESULT hr = obj.QueryInterface(...);
   }


> I don't think this is a desirable approach because it makes interfaces
> a strictly non-modular concept, and might force library designers to
> add unique prefixes to interface subprogram names.

In the example above, both I1::QueryInterface and I2::QueryInterface do
exactly the same thing, so the same subprogram should be called.

If you have a true name clash (meaning that two separate interfaces have
the same name for an operation that does completly different things),
then all you have to do is declare one of the interfaces as a nested
class (in Ada-speak, that would be a "multiple views idiom"):

  class C : public I1 
  {
  public:
     void foo();  //I1::foo()

     class C2 : public I2 
     {
        void foo();
     };

     C2 m_obj2;
  };

Now you can say:

   void f(C& obj)
   {
      obj.foo();  //I1
      obj.m_obj2.foo();  //I2
   }

You don't have to have unique prefixes or anything for your interface
types, since the outer class serves in effect as the prefix.

Note that COM hides the nesting behind QueryInterface.  That's more or
less how the multiple views idiom works in Ada:

   type T is limited private;

   function Get_I1 (O : access T) return I1_Access;
   function Get_I2 (O : access T) return I2_Access;

So instead of:

  Foo ((J1 (T_Obj));
  Foo ((J2 (T_Obj));

You would say:

   Foo (Get_I1 (T_Obj'Access).all);
   Foo (Get_I2 (T_Obj'Access).all);

Being able to inherit from multiple interface types is mostly a
syntactic convenience.  Nested classes work in COM, and the multiple
views idiom works in Ada95.

Calling Foo as in your example is a statement that I1::Foo and I2::Foo
do the same thing.  (Like QueryInterface, or AddRef, etc.)  If you want
to overload the name Foo across interface types, then fine, just revert
to the multiple views idiom for one or both of the interface types.

-Matt