comp.lang.ada
 help / color / mirror / Atom feed
From: Robert A Duff <bobduff@shell01.TheWorld.com>
Subject: Re: Interfaces
Date: 16 May 2005 14:59:45 -0400
Date: 2005-05-16T14:59:45-04:00	[thread overview]
Message-ID: <wccoebbj8ta.fsf@shell01.TheWorld.com> (raw)
In-Reply-To: 8764xj9wzf.fsf@deneb.enyo.de

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



  parent reply	other threads:[~2005-05-16 18:59 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-16 12:27 Interfaces Florian Weimer
2005-05-16 16:13 ` Interfaces Georg Bauhaus
2005-05-16 16:12   ` Interfaces Florian Weimer
2005-05-16 18:59 ` Robert A Duff [this message]
2005-05-16 19:27   ` Interfaces Florian Weimer
2005-05-16 20:09     ` Interfaces Robert A Duff
2005-05-16 20:44       ` Interfaces Florian Weimer
2005-05-17  6:14     ` Interfaces Vinzent 'Gadget' Hoefler
2005-05-17 10:53       ` Interfaces Florian Weimer
2005-05-17 13:34         ` Interfaces Vinzent 'Gadget' Hoefler
     [not found]         ` <4289f382$0$10805$afc38c87@>
2005-05-17 16:51           ` Interfaces Pascal Obry
     [not found]             ` <428a2832$0$10805$afc38c87@>
2005-05-17 18:15               ` Interfaces Pascal Obry
2005-05-17 21:11                 ` Interfaces Florian Weimer
2005-05-18 10:36                   ` Interfaces Georg Bauhaus
2005-05-17  7:36     ` Interfaces Dmitry A. Kazakov
2005-05-17  9:06       ` Interfaces Florian Weimer
2005-05-17 10:19         ` Interfaces Dmitry A. Kazakov
2005-05-17 10:57           ` Interfaces Florian Weimer
2005-05-17 11:13             ` Interfaces Dmitry A. Kazakov
2005-05-17 15:35               ` Interfaces Robert A Duff
2005-05-17 21:53                 ` Interfaces Florian Weimer
2005-05-17 23:21                   ` Interfaces Randy Brukardt
2005-05-17 23:44                     ` Interfaces Marius Amado Alves
2005-05-18  7:53                     ` Interfaces Dmitry A. Kazakov
2005-05-18 16:57 ` Interfaces adam
2005-05-20  5:31 ` Interfaces Matthew Heaney
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox