| Accueil de l'archive | Service proposé par Hervé AGNOUX |
Date sent: Fri, 21 Jan 2000 08:33:44 +0100
From: Frederic LAURENT <frederic.laurent@sxb.bsf.alcatel.fr>
To: liste java <java@u-strasbg.fr>
Subject: bug sur les interfaces ?
Send reply to: java@u-strasbg.fr
Salut,
Je joins un petit programme illustrant d'aprés moi un bug.
Il passe à la compil alors qu'il ne devrait pas. En effet,
la classe qui implémente le Listener ne redéfinie pas la
méthode de l'interface ActionListener. A partir du moment
où une méthode dans la hierarchie portant le bon nom est
trouvé, java est content...
Cependant la méthode pourrait n'avoir aucun rapport avec
le service attendu, d'où ma question, d'après vous,
est-ce un bug ou pas ?
Fred
---------------------------------------------------
// jdk 1.1.8_09
import java.awt.*;
import java.awt.event.*;
class ActionA {
public ActionA() {}
public void actionPerformed(ActionEvent e) {
System.out.println("Click ActionA");
}
}
class ActionB extends ActionA
implements ActionListener {
public ActionB() {}
}
class testFrame extends Frame {
Button mBouton = new Button("Click");
public testFrame() {
mBouton.addActionListener(new ActionB());
add(mBouton);
pack();
show();
}
}
public class testinterface {
public static void main (String[] args) {
testFrame mframe = new testFrame();
}
}
--
Frédéric LAURENT
mailto:frederic.laurent@sxb.bsf.alcatel.fr
Tél : (33) 03 88 67 77 00 poste 74701
From: Damien.Menanteau@alcatel.fr To: java@u-strasbg.fr Date sent: Fri, 21 Jan 2000 09:04:32 +0100 Subject: Re: bug sur les interfaces ? Send reply to: java@u-strasbg.fr C'est tout sauf un bug. Ca met au contraire en evidence la puissance du mecanisme d'heritage. Lorsqu'une classe implemente une interface, il suffit qu'elle, ou l'une de ses classes parentes, implemente les differentes methodes de l'interface. Quant-au risque que tu evoques, c'est simplement un probleme de maitrise de ton arbre d'heritage. En general lorsque l'on decide d'heriter d'une classe, ce n'est pas par hasard, et le but premier est d'heriter d'un maximum de ses caracteristiques. Si celles-ci ne te conviennent pas, tu les redefinis. Si tu dois toutes les redefinir, tu peux commencer a te demander si ton choix d'heritage est vraiment approprie. Damien Frederic LAURENT <frederic.laurent@sxb.bsf.alcatel.fr> on 21/01/2000 08:33:44 Please respond to java@u-strasbg.fr To: liste java <java@u-strasbg.fr> cc: (bcc: Damien MENANTEAU/FR/ALCATEL) Subject: bug sur les interfaces ?
From: zze-minitel2001 balr001 <minitel2001.balr001@cnet.francetelecom.fr>
To: "'java@u-strasbg.fr'" <java@u-strasbg.fr>
Subject: RE: bug sur les interfaces ?
Date sent: Fri, 21 Jan 2000 12:05:10 +0100
Send reply to: java@u-strasbg.fr
> C'est tout sauf un bug. Ca met au contraire en evidence la
> puissance du mecanisme d'heritage. Lorsqu'une classe
> implemente une interface, il suffit qu'elle, ou l'une de ses
> classes parentes, implemente les differentes methodes de l'interface.
C'est écrit comme ca dans la spec?
Si B hérite de A et que B implémente I, il me semble dommage qu'une partie
de l'implémentation de I soit déléguée à A. Tout simplement parceque A
n'implémente pas I. Donc la méthode fournie par A ne devrait pas matcher
avec la méthode de I. Pour moi non plus ce code ne devrait pas compiler,
car il une grave faute derrière tout ca.
> Quant-au risque que tu evoques, c'est simplement un probleme
> de maitrise de ton arbre d'heritage.
Ca peut effectivement poser un problème avec des noms de méthodes
bateau (init, start, stop) qui peuvent exister dans n'importe quelle
classe.
> En general lorsque l'on decide d'heriter d'une classe, ce n'est pas par
hasard,
> et le but premier est d'heriter d'un maximum de ses caracteristiques.
> Si celles-ci ne te conviennent pas, tu les redefinis. Si tu dois toutes
> les redefinir, tu peux commencer a te demander si ton choix d'heritage
> est vraiment approprie.
>
> Damien
Le cas don parle Fred est source de Bug :
class A
{
...
public A void copy () // Nom de méthode bateau
...
}
Interface AConvertible
{
public A void Copy();
}
class B extends A implements AConvertible
{
// J'oublie de définir Copy, normalement le compilateur devrait me
le dire.
}
L'exemple est complètement con mais peut arriver de manière plus
vicieuse dans une plus grande masse de code.
Le bug peut etre pénible a trouver dans ce cas.
Quelqu'un sait ce que dit la spec à ce sujet?
A+
Daniel
Date sent: Fri, 21 Jan 2000 14:08:41 +0100 From: Frederic LAURENT <frederic.laurent@sxb.bsf.alcatel.fr> To: java@u-strasbg.fr Subject: Re: bug sur les interfaces ? Send reply to: java@u-strasbg.fr Damien.Menanteau@ALCATEL.FR wrote: > C'est tout sauf un bug. Ca met au contraire en evidence la puissance du > mecanisme d'heritage. Lorsqu'une classe implemente une interface, il > suffit qu'elle, ou l'une de ses classes parentes, implemente les > differentes methodes de l'interface. Il n'empêche que si la classe parente définit un service m(), qui n'a rien à voir avec un service m() d'une interface implémentée par la classe fille, des confusions peuvent se produire sans que le compilateur ne dise quoi que ce soit. > > Quant-au risque que tu evoques, c'est simplement un probleme de maitrise > de ton arbre d'heritage. Et bien justement, tu ne maitrises pas toujours les classes dont tu hérites...A partir du moment où tu récupères une classe qui t'intéresse mais que tu ne peux la modifier, ta maitrise est linitée... > En general lorsque l'on decide d'heriter d'une classe, ce n'est pas par > hasard, et le but premier est d'heriter d'un maximum de ses > caracteristiques. Si celles-ci ne te conviennent pas, tu les redefinis. > Si tu dois toutes les redefinir, tu peux commencer a te demander si ton > choix d'heritage est vraiment approprie. > il suffit d'une seule méthode rentrant dans ce shéma pour que tout s'embrouille...Et dans un projet de plus de 50 personnes, des classes et des héritages, il y en a quelques uns... > > Damien > Fred -- Frédéric LAURENT mailto:frederic.laurent@sxb.bsf.alcatel.fr Tél : (33) 03 88 67 77 00 poste 74701
From: cedric.beust@beasys.com (Cedric Beust)
To: <java@u-strasbg.fr>
Subject: RE: bug sur les interfaces ?
Date sent: Fri, 21 Jan 2000 10:40:35 -0800
Send reply to: java@u-strasbg.fr
> From: zze-minitel2001 balr001
> [mailto:minitel2001.balr001@cnet.francetelecom.fr]
> C'est écrit comme ca dans la spec?
> Si B hérite de A et que B implémente I, il me semble dommage qu'une
> partie de l'implémentation de I soit déléguée à A. Tout simplement
> parceque A n'implémente pas I. Donc la méthode fournie par A ne devrait
> pas matcher avec la méthode de I. Pour moi non plus ce code ne devrait
> pas compiler, car il une grave faute derrière tout ca.
Non au contraire, c'est ce mecanisme qui sous-tend des idiomes capitaux
comme les Adapteurs.
Cela permet de conjuguer heritage d'interface et heritage
d'implementation.
Une facon classique de proceder est de definir une interface, puis une
classe implementant partiellement (ou completement, mais avec des methodes
vides) cette interface. Ensuite il suffit d'heriter l'implementation pour
obtenir un comportement par defaut raisonnable.
Cet idiome est utilise a plusieurs endroits dans l'AWT.
Si on n'avait pas ca, le polymoprhisme ne fonctionnerait tout simplement
pas en Java... (essaie d'imaginer les consequences).
> Ca peut effectivement poser un problème avec des noms de méthodes
> bateau (init, start, stop) qui peuvent exister dans n'importe quelle
> classe.
Une tres bonne raison pour donner des noms de methode plus explicites (au
moins verbe + nom personnellement).
> Le cas don parle Fred est source de Bug :
>
> class A
> {
> ...
> public A void copy () // Nom de méthode bateau
> ...
> }
>
> Interface AConvertible
> {
> public A void Copy();
> }
>
> class B extends A implements AConvertible
> {
> // J'oublie de définir Copy, normalement le compilateur devrait me le
> dire.
> }
Non ! Imagine le nombre de messages d'erreurs que tu obtiendrais pour
toutes les autres classes !!!
> Quelqu'un sait ce que dit la spec à ce sujet?
La spec est tres claire : c'est autorise.
Et elle est en accord avec toute la communaute OO sur ce point : c'est une
Bonne Chose.
--
Cedric
http://beust.com/cedric
From: "Herve AGNOUX" <hagnoux@mail.club-internet.fr> To: java@u-strasbg.fr Date sent: Fri, 21 Jan 2000 20:50:14 +0100 Subject: Re: bug sur les interfaces ? Priority: normal Send reply to: java@u-strasbg.fr Le 21 Jan 00, Frederic LAURENT a écrit : > Damien.Menanteau@ALCATEL.FR wrote: > > > C'est tout sauf un bug. Ca met au contraire en evidence la puissance > > du > [...] > Il n'empêche que si la classe parente définit un service m(), qui n'a > rien à voir avec un service m() d'une interface implémentée par la > classe fille, des confusions peuvent se produire sans que le compilateur > ne dise quoi que ce soit. > Je ne vois pas pourquoi tu distingues le service m() de la fille de celui de la parente. Si la parente définit un service m(), il est aussi définit pour les classes filles, c'est comme ça. Tu sembles craindre qu'il existe un risque au niveau de la sémantique du service m(), c'est à dire qu'il ait un certain sens dans l'interface, et que par accident une classe X définisse un service m() avec le même nom mais qui n'ait pas du tout la même signification (dit moi si je me trompe). A ma connaissance seule ta façon de désigner tes identificateurs te permet d'éviter ça (les règles de nomage). Dans tous les langages c'est comme ça. > > > > > Quant-au risque que tu evoques, c'est simplement un probleme de > > maitrise de ton arbre d'heritage. > > Et bien justement, tu ne maitrises pas toujours les classes dont tu > hérites...A partir du moment où tu récupères une classe qui t'intéresse > mais que tu ne peux la modifier, ta maitrise est linitée... > Normalement les classes issues de bibliothèques externes sont dans des paquages séparés. Il est parfaitement clair qu'il FAUT maîtriser ton arbre d'héritage, MEME pour les classes que tu récupères. Le système des paquages t'y aide, et j'avoue que je ne vois pas dans quels cas on peut se retrouver avec des classes filles déclarant par hasard (?) une interface parasite (?). > > > En general lorsque l'on decide d'heriter d'une classe, ce n'est pas > > par hasard, et le but premier est d'heriter d'un maximum de ses > > caracteristiques. Si celles-ci ne te conviennent pas, tu les > > redefinis. Si tu dois toutes les redefinir, tu peux commencer a te > > demander si ton choix d'heritage est vraiment approprie. > > Oui, absolument. > > il suffit d'une seule méthode rentrant dans ce shéma pour que tout > s'embrouille...Et dans un projet de plus de 50 personnes, des classes et > des héritages, il y en a quelques uns... > C'est justement dans ce genre de projet qu'il faut finasser sur les règles de nommage, l'arborescence des classes et la distribution des paquages. Il faut que tu trouves les moyens de le faire. Java te proposes une organisation objet qui est pour l'essentiel conforme au règles de l'art, y compris pour les interfaces, c'est tout, c'est beaucoup. -- Hervé AGNOUX hagnoux@mail.club-internet.fr Faites vos sites avec des formulaires electroniques : http://www.diaam.com
From: "Thomas Landspurg" <tomsoft@iname.com>
To: <java@u-strasbg.fr>
Subject: Re: bug sur les interfaces ?
Date sent: Sat, 22 Jan 2000 15:46:12 +0100
Send reply to: java@u-strasbg.fr
-----Message d'origine-----
De : Herve AGNOUX <hagnoux@mail.club-internet.fr>
À : java@u-strasbg.fr <java@u-strasbg.fr>
Date : vendredi 21 janvier 2000 20:52
Objet : Re: bug sur les interfaces ?
>Le 21 Jan 00, Frederic LAURENT a écrit :
>
>
>Normalement les classes issues de bibliothèques externes sont
>dans des paquages séparés. Il est parfaitement clair qu'il FAUT
>maîtriser ton arbre d'héritage, MEME pour les classes que tu
>récupères. Le système des paquages t'y aide, et j'avoue que je ne
>vois pas dans quels cas on peut se retrouver avec des classes
>filles déclarant par hasard (?) une interface parasite (?).
>
Je ne vois pas de quelle maniere le systeme de packetage t'apporte une
quelconque utilitée dans ce cas present.
>C'est justement dans ce genre de projet qu'il faut finasser sur les
>règles de nommage, l'arborescence des classes et la distribution
>des paquages. Il faut que tu trouves les moyens de le faire. Java te
>proposes une organisation objet qui est pour l'essentiel conforme au
>règles de l'art, y compris pour les interfaces, c'est tout, c'est
>beaucoup.
>
Il reste quand même que ce problème est un bug: pour qu'une objet
implemente une interface, il faut deux choses conjointes: qu'il declare de
manière explicite son désire d'implementer une interface (le mot clef
implement) et qu'ensuite il implémente les méthodes de l'interface, sous
peine d'erreur à la compil.
Or, dans l'exemple donné, on a d'un coté une classe qui déclare
l'implementation sans avoir besoin de l'implementer, et qui hérite d'une
classe qui contient une methode n'ayant a priori rien a voir avec
l'interface à part le nom. C'est un cas typique de bug. Meme si le
compilateur peut laisser passer cela, un warning aurzit été le bienvenu.
C'est evident qu'il faut maitriser l'arbe d'heritage, mais le langage
doit
autant que faire se peut t'aider a le maitriser. Or, la, de toute evidence
ce n'est pas le cas.
>
>--
>Hervé AGNOUX hagnoux@mail.club-internet.fr
>Faites vos sites avec des formulaires electroniques :
>http://www.diaam.com
>
From: "Thomas Landspurg" <tomsoft@iname.com>
To: <java@u-strasbg.fr>
Subject: Re: bug sur les interfaces ?
Date sent: Sat, 22 Jan 2000 16:00:09 +0100
Send reply to: java@u-strasbg.fr
-----Message d'origine-----
De : Cedric Beust <cedric.beust@beasys.com>
À : java@u-strasbg.fr <java@u-strasbg.fr>
Date : vendredi 21 janvier 2000 19:43
Objet : RE: bug sur les interfaces ?
>> From: zze-minitel2001 balr001
>> [mailto:minitel2001.balr001@cnet.francetelecom.fr]
>
>> C'est écrit comme ca dans la spec?
>> Si B hérite de A et que B implémente I, il me semble dommage qu'une
partie
>> de
>> l'implémentation de I soit déléguée à A.
>> Tout simplement parceque A n'implémente pas I. Donc la méthode fournie
par A
>> ne devrait
>> pas matcher avec la méthode de I.
>> Pour moi non plus ce code ne devrait pas compiler, car il une grave
>> faute derrière tout ca.
>
>Non au contraire, c'est ce mecanisme qui sous-tend des idiomes capitaux
comme
>les Adapteurs.
>
>Cela permet de conjuguer heritage d'interface et heritage
>d'implementation.
>
>Une facon classique de proceder est de definir une interface, puis une
classe
>implementant partiellement (ou completement, mais avec des methodes
>vides) cette interface. Ensuite il suffit d'heriter l'implementation pour
>obtenir
un
>comportement par defaut raisonnable.
>
Oui, mais si j'ai bien compris, le cas cité n'est pas celui que
tu
décris
>Cet idiome est utilise a plusieurs endroits dans l'AWT.
Un exemple?
>
>--
>Cedric
>http://beust.com/cedric
>
>
Date sent: Sat, 22 Jan 2000 16:07:05 +0100 From: William Dodé <wilk@chez.com> Send reply to: wilk@chez.com Organization: Informaticien Indépendant To: java@u-strasbg.fr Subject: Re: bug sur les interfaces ? Salut, Pour moi il ne sagit pas d'un bug. Lorsqu'on hérite d'une classe c'est sous entendu que l'on hérite de TOUT, y compris des implémentations. C'est pour cela je pense que dans la nouvelle doc du jdk1.2 sont indiqués toutes les implémentations, y compris celles héritées. Nous sommes donc sensés les conaîtres "nul n'est sensé ignorer les implémentations"... En attendant je me fait toujours piéger régulièrement avec ce genre de trucs... Au passage, la dernière mouture de kawa (3.5) permet le code completion (pas mal pour éviter les erreurs de frappe en redéfinition de méthode). a +++ -- William Dodé --- Informaticien Indépendant http://www.chez.com/wilk <mailto:wilk@chez.com>
From: zze-minitel2001 balr001 <minitel2001.balr001@cnet.francetelecom.fr>
To: "'java@u-strasbg.fr'" <java@u-strasbg.fr>
Subject: RE: bug sur les interfaces ?
Date sent: Mon, 24 Jan 2000 11:25:20 +0100
Send reply to: java@u-strasbg.fr
> > C'est écrit comme ca dans la spec?
> > Si B hérite de A et que B implémente I, il me semble
> dommage qu'une partie
> > de
> > l'implémentation de I soit déléguée à A.
> > Tout simplement parceque A n'implémente pas I. Donc la
> méthode fournie par A
> > ne devrait
> > pas matcher avec la méthode de I.
> > Pour moi non plus ce code ne devrait pas compiler, car il
> une grave faute
> > derrière tout ca.
>
> Non au contraire, c'est ce mecanisme qui sous-tend des
> idiomes capitaux comme
> les Adapteurs.
Ton exemple sur les Adapters est faux.
Pour fournir une base d'implémentation d'une interface donnée,
les Adapters implémentent cette interface :
public abstract class WindowAdapter
extends Object
implements WindowListener
Dans l'exemple que je donne, A (qui est l'adapter selon toi) n'implémente
pas I.
> Si on n'avait pas ca, le polymoprhisme ne fonctionnerait tout
> simplement pas
> en Java... (essaie d'imaginer les consequences).
Si on avait pas la *fonctionnalité* dont parle Fred, le polymorphisme
continuerait à très bien fonctionner.
> > Ca peut effectivement poser un problème avec des noms de méthodes
> > bateau (init, start, stop) qui peuvent exister dans n'importe quelle
> > classe.
>
> Une tres bonne raison pour donner des noms de methode plus
> explicites (au moins verbe + nom personnellement).
C'est vrai, je me suis laissé aller la :)
> > Le cas don parle Fred est source de Bug :
> >
> > class A
> > {
> > ...
> > public A void copy () // Nom de méthode bateau
> > ...
> > }
> >
> > Interface AConvertible
> > {
> > public A void Copy();
> > }
> >
> > class B extends A implements AConvertible
> > {
> > // J'oublie de définir Copy, normalement le compilateur
> devrait me
> > le dire.
> > }
>
> Non ! Imagine le nombre de messages d'erreurs que tu
> obtiendrais pour toutes
> les autres classes !!!
Logique, pour moi si on veut résoudre le problème il faut indiquer
que A implément AConvertible.
> Quelqu'un sait ce que dit la spec à ce sujet?
>
> La spec est tres claire : c'est autorise.
>
> Et elle est en accord avec toute la communaute OO sur ce
> point : c'est une
> Bonne Chose.
Alors moi aussi, je vais être très clair :
je m'exclue moi même du mouvement et j'affirme
haut et fort que je ne suis pas convaincu !!!! ;)
Halte aux spécifications fallacieuses!! Halte au dictat de
la communauté OO!!! Vive l'héritage libre !!
Vous l'aurez compris, ces dernières lignes ne sont
pas a prendre au serieux.
A+
Daniel
Date sent: Mon, 24 Jan 2000 15:18:48 +0100 From: Rodrigo Reyes <rodrigo.reyes@lcr.thomson-csf.com> Organization: Thomson-CSF Laboratoire Central de Recherches Copies to: java@u-strasbg.fr Subject: Re: bug sur les interfaces ? Send reply to: java@u-strasbg.fr William =?iso-8859-1?Q?Dod=E9?= a écrit : > En attendant je me fait toujours piéger régulièrement avec ce genre de > trucs... Au passage, la dernière mouture de kawa (3.5) permet le code > completion (pas mal pour éviter les erreurs de frappe en redéfinition de > méthode). Emacs aussi avec le JDE, d'ailleurs. -- Rodrigo. Mes propos ne sont pas | #include <disclaimer> ceux de mon employeur | Socrate: "vous dites que j'ai bu quoi ?"
Send reply to: "KEOPS" <e.ostenne@mail.ac-lille.fr>
From: "KEOPS" <e.ostenne@mail.ac-lille.fr>
To: <java@u-strasbg.fr>
Subject: Re: bug sur les interfaces ?
Date sent: Mon, 24 Jan 2000 16:10:29 +0100
Organization: KEOPS
In french in the text : que dois-je comprendre par ce message ?
------------------------------------------------------------
Keops (Emmanuel Ostenne)
/
==========================\ \_ Déclic, la géométrie sous Windows /_ http://home.nordnet.fr/~eostenne \_ Les mathématiques sur ordinateur /_ http://www.lille.iufm.fr/lilimath \================================/ ----- Message d'origine ----- De : Rodrigo Reyes <rodrigo.reyes@lcr.thomson-csf.com> À : <e.ostenne@mail.ac-lille.fr> Cc : <java@u-strasbg.fr> Envoyé : lundi 24 janvier 2000 15:18 Objet : Re: bug sur les interfaces ? > William =?iso-8859-1?Q?Dod=E9?= a écrit : > > > En attendant je me fait toujours piéger régulièrement avec ce genre de > > trucs... Au passage, la dernière mouture de kawa (3.5) permet le code > > completion (pas mal pour éviter les erreurs de frappe en redéfinition > > de méthode). > > Emacs aussi avec le JDE, d'ailleurs. > > > -- > Rodrigo. > > Mes propos ne sont pas | #include <disclaimer> > ceux de mon employeur | Socrate: "vous dites que j'ai bu quoi ?" >
From: cedric.beust@beasys.com (Cedric Beust) To: <java@u-strasbg.fr> Subject: RE: bug sur les interfaces ? Date sent: Mon, 24 Jan 2000 08:25:00 -0800 Send reply to: java@u-strasbg.fr > From: Thomas Landspurg [mailto:tomsoft@iname.com] > Sent: Saturday, January 22, 2000 7:00 AM > >Cet idiome est utilise a plusieurs endroits dans l'AWT. > > Un exemple? Toutes les classes finissant par "Adapter", comme java.awt.event.MouseAdapter. -- Cedric http://beust.com/cedric
From: cedric.beust@beasys.com (Cedric Beust) To: <java@u-strasbg.fr> Subject: RE: bug sur les interfaces ? Date sent: Mon, 24 Jan 2000 08:25:01 -0800 Send reply to: java@u-strasbg.fr > From: zze-minitel2001 balr001 > [mailto:minitel2001.balr001@cnet.francetelecom.fr] > Alors moi aussi, je vais être très clair : > je m'exclue moi même du mouvement et j'affirme > haut et fort que je ne suis pas convaincu !!!! ;) > Halte aux spécifications fallacieuses!! Halte au dictat de > la communauté OO!!! Vive l'héritage libre !! :-) Pour ceux interesses par les raisons plus profondes du fonctionnement actuel, je vous recommande la lecture de "Design and Evolution of C++", de Bjarne Stroustrup. Et plus precisement, la section ou il explique pourquoi l'inclusion d'un nouveau mot-cle "override" dans C++ a ete rejetee. -- Cedric http://beust.com/cedric
From: cedric.beust@beasys.com (Cedric Beust) To: <java@u-strasbg.fr> Subject: RE: bug sur les interfaces ? Date sent: Mon, 24 Jan 2000 08:33:25 -0800 Send reply to: java@u-strasbg.fr > From: Rodrigo Reyes [mailto:rodrigo.reyes@lcr.thomson-csf.com] > Emacs aussi avec le JDE, d'ailleurs. Ah ?!? Pas dans la version que j'ai. Quelle version utilises-tu ? A ce jour, la completion la plus impressionnante que j'ai utilisee est celle de VJ++. A tel point que ca devient quasiment une partie de ma saisie (si le popup n'apparait pas, je sais que j'ai fait une erreur quelque part). Et saisir le code avec la signature de la fonction immediatement sous les yeux, c'est incroyablement pratique. Celle de Visual Cafe est nettement moins bonne, mais correcte quand meme (version 3, pas teste la version 4). -- Cedric
From: "Thomas Landspurg" <tomsoft@iname.com> To: <java@u-strasbg.fr> Subject: Re: bug sur les interfaces ? Date sent: Mon, 24 Jan 2000 18:08:00 +0100 Send reply to: java@u-strasbg.fr Oui, mais les adapters sont bien des implementations des interfaces, avec le mot cléf "implement". Donc il n'y a pas de confusion! Ce qui est la parfaitement coherent! Donc soit je n'ai pas compris le problème, soit tu ne l'a pas compris :-) -----Message d'origine----- De : Cedric Beust <cedric.beust@beasys.com> À : java@u-strasbg.fr <java@u-strasbg.fr> Date : lundi 24 janvier 2000 17:30 Objet : RE: bug sur les interfaces ? >> From: Thomas Landspurg [mailto:tomsoft@iname.com] >> Sent: Saturday, January 22, 2000 7:00 AM > >> >Cet idiome est utilise a plusieurs endroits dans l'AWT. >> >> Un exemple? > >Toutes les classes finissant par "Adapter", comme java.awt.event.MouseAdapter. > >-- >Cedric >http://beust.com/cedric > >
Date sent: Tue, 25 Jan 2000 11:32:40 +0100 From: Rodrigo Reyes <rodrigo.reyes@lcr.thomson-csf.com> Organization: Thomson-CSF Laboratoire Central de Recherches Copies to: java@u-strasbg.fr Subject: Re: bug sur les interfaces ? Send reply to: java@u-strasbg.fr KEOPS a écrit : > > > trucs... Au passage, la dernière mouture de kawa (3.5) permet le > > > code completion (pas mal pour éviter les erreurs de frappe en > > > redéfinition de méthode). > > Emacs aussi avec le JDE, d'ailleurs. > In french in the text : que dois-je comprendre par ce message ? Rien de plus que ce qu'il dit : que la dernière version du JDE pour Emacs (http://sunsite.auc.dk/jde) implémente également une complétion intelligente pour les méthodes des objets. C'est à peu près équivalent à l'intellisense qu'on trouve couramment sous windows. -- Rodrigo. Mes propos ne sont pas | #include <disclaimer> ceux de mon employeur | Socrate: "vous dites que j'ai bu quoi ?"
Date sent: Tue, 25 Jan 2000 11:37:18 +0100 From: Rodrigo Reyes <rodrigo.reyes@lcr.thomson-csf.com> Organization: Thomson-CSF Laboratoire Central de Recherches To: java@u-strasbg.fr Subject: Re: bug sur les interfaces ? Send reply to: java@u-strasbg.fr Cedric Beust a écrit : > > From: Rodrigo Reyes [mailto:rodrigo.reyes@lcr.thomson-csf.com] > > Emacs aussi avec le JDE, d'ailleurs. > Ah ?!? Pas dans la version que j'ai. Quelle version utilises-tu ? Dans la version béta actuelle. C'est d'ailleurs une fonctionnalité écrite par ton serviteur. Elle peut marcher sans le JDE à proprement parler, mais il lui faut bsh car elle a besoin d'appeller du code Java (la réflection, en fait). > A ce jour, la completion la plus impressionnante que j'ai utilisee est > celle de VJ++. A tel point que ca devient quasiment une partie de ma > saisie (si le popup n'apparait pas, je sais que j'ai fait une erreur > quelque part). Et saisir le code avec la signature de la fonction > immediatement sous les yeux, c'est incroyablement pratique. Tout à fait. Celle que j'ai écrite ne fait pas ça, parce que ce n'est pas évident à faire sous Emacs, et surtout que ce n'est pas trop dans l'esprit de l'éditeur, mais je suis tout à fait d'accord sur le fait que ce genre de fonctionnalité est une réelle avancée dans l'ergonomie de la programmation. -- Rodrigo. Mes propos ne sont pas | #include <disclaimer> ceux de mon employeur | Socrate: "vous dites que j'ai bu quoi ?"
Date sent: Tue, 25 Jan 2000 15:03:45 +0100
From: Frederic LAURENT <frederic.laurent@sxb.bsf.alcatel.fr>
To: java@u-strasbg.fr
Subject: Re: bug sur les interfaces ?
Send reply to: java@u-strasbg.fr
Je vais essayer de préciser ma pensée.
En fait, il me semble dommage que le compilateur java se
borne (dans ce cas, au diable les généralités faciles) à
une compilation syntaxique et non sémantique.
A fournit une méthode m
B implémente I qui demande une méthode m, et B dérive de A
et voilà le tour est joué.
Alors que pour moi, quand on implémente une interface, il y a
une sémantique derriére, c'est à dire que le service offert
par l'opération m de A n'a rien à voir avec le service
proposé par I, puisque A n'implémente pas I.
Une insulte à la compilation serait la bienvenue, du style
il y a confusion entre la méthode m provenant de l'interface
et la méthode m provenant de la classe mère.
En C++, le problème ne se pose pas, car le compilateur ne
laisse pas passer cela: ex
---------------fichier A.h--------------
#include <iostream.h>
class A {
public:
A() {}
void m() { cout << "classe A" << endl; }
};
---------------fichier B.h--------------
#include <iostream.h>
class B {
public:
B() {}
void m() { cout << "classe B" << endl; }
};
---------------fichier C.h--------------
#include "A.h"
#include "B.h"
class C : public A, public B {
public:
C() {}
};
---------------fichier testmulti.cpp--------------
#include "C.h"
main()
{
C testClass;
testClass.m();
}
---------------------------------------------------
résultat de la compilation :
g++ testmulti.cpp
testmulti.cpp: In function `int main()':
testmulti.cpp:7: request for method `m' is ambiguous
Et je trouve cela normal !
Certains rétorquent qu'il faut maîtriser l'arbre d'héritage,
définir des règles de nommage, et hop cela résoud tous les
problèmes. Cependant, puisqu'il faut s'employer à faire
attention à ne pas faire n'importe quoi, pourquoi ne pas
l'interdire dès le départ. Ainsi, on lève les ambiguités, non?
Et puis à partir du moment où s'est autorisé, par définition
on peut le faire, malgré tout le bon sens de chacun, et donc
c'est dangereux.
Je peux donner un autre exemple qui me laisse perplexe et qui
marche parfaitement (cf source)
class ActionA implements ActionListener {
class ActionB extends ActionA implements ActionListener {
Pourquoi le compilateur ne crache-t-il pas une insulte
quand B implémente ActionListener, puisque la classe mère
s'en charge déjà ?
Quelle est la signification de ce code ? Il est difficile
de savoir ce que l'on veut vraiment faire, non ?
Alors évidemment le bon sens résoud le problème, mais je
trouve que ce n'est pas suffisant.
En plus on retrouve l'instruction d'implémentation dans le
byte code des 2 classes.
voila, votre avis m'intéresse...
------------------------------------------------
import java.awt.*;
import java.awt.event.*;
class ActionA implements ActionListener {
public ActionA() {}
public void actionPerformed(ActionEvent e) {
System.out.println("Click ActionA");
}
}
class ActionB extends ActionA implements ActionListener {
public ActionB() {}
}
class testFrame extends Frame {
Button mBouton = new Button("Click");
public testFrame() {
mBouton.addActionListener(new ActionB());
add(mBouton);
pack();
show();
}
}
public class testinterface {
public static void main (String[] args) {
testFrame mframe = new testFrame();
}
}
--
Frédéric LAURENT
mailto:frederic.laurent@sxb.bsf.alcatel.fr
Tél : (33) 03 88 67 77 00 poste 74701
Date sent: Tue, 25 Jan 2000 16:40:11 +0100
From: Guillaume Desnoix <guillaume-desnoix@memoire.com>
To: java@u-strasbg.fr
Subject: Re: bug sur les interfaces ?
Send reply to: java@u-strasbg.fr
Frederic LAURENT wrote:
> Alors que pour moi, quand on implémente une interface, il y a
> une sémantique derriére, c'est à dire que le service offert
> par l'opération m de A n'a rien à voir avec le service
> proposé par I, puisque A n'implémente pas I.
> Une insulte à la compilation serait la bienvenue, du style
> il y a confusion entre la méthode m provenant de l'interface
> et la méthode m provenant de la classe mère.
Je suis d'accord, ce serait plus propre si il fallait redefinir m().
D'un autre cote, ca peut obliger la definition de code vide type: void m()
{ super.m(); } ce qui n'est pas terrible non plus (mais plus clair). Mais
comme en general les interfaces presentent un jeu reduit de methodes, ce
serait la bonne solution (avec toutefois une petite perte de perf).
> En C++, le problème ne se pose pas, car le compilateur ne
> laisse pas passer cela.
Forcement, le C++ ne connaissant pas la notion d'interface... Par contre
il y a une erreur en cas de conflit dans la resolution de l'heritage
multiple. Mais c'est un autre probleme... Si tu utilises des classes
abstraites et/ou vides C++ comme des interfaces, tu retombes sur le meme
probleme...
Guillaume
From: jean-philippe.bret@certia.cnafmail.fr To: java@u-strasbg.fr Date sent: Tue, 25 Jan 2000 16:48:26 +0100 Subject: Réf. : Re: bug sur les interfaces ? Send reply to: java@u-strasbg.fr en réponse à Frederic Laurent : J'improvise une intervention dans ce long débat ... même si je n'ai pas l'expertise que vous semblez tous avoir en la matière. Visiblement, il y a deux écoles dans ces exemples : l'héritage multiple et les interfaces. Je pense qu'il est normal, dans le cas de l'héritage multiple, de se faire jeter par le compilateur. Une solution (peut être possible) serait de faire un cast sur l'instance qui evoque cette méthode m(). Ainsi, on pourrait indiquer la méthode que l'on utilise. Ex : pour la classe X , ((X) monInstance).m() Vous noterez au passage que j'ai bien retenu la leçon sur le cast ;-) Mais là n'est pas la question... Dans le cas des interfaces, il s'agit d'un autre concept : celui du Contrat que la classe implémentante accepte de remplir en réalisant les méthodes déclarées dans l'interface. Si la classe A hérite de B et ainsi réalise le contrat passé avec I, alors pas de problème. Point de vue sémantique, si B et I ont une méthode qui porte le même nom, il y a peut être un problème d'analyse ? B.m() et I.m() ont peut être quelque chose de commun ? alors on peut remettre en question le choix de faire hériter A de B... Peut être que ces deux méthodes n'ont rien à voir ? alors on peut se demander pourquoi elles s'appellent par le même nom et y remédier (quand c'est possible). Il est tellement facile de jouer sur les mots (en analyse tout du moins) qu'on peut très bien arriver à la situation suivante : imaginons un projet informatique dans une écurie de formule 1... on modélise la voiture etc et le pilote. Et puis on veut importer un package prêt à l'emploi pour gérer des appareils de mesure embarqués. Ce package utilise des pilotes (drivers) pour s'interfacer avec les équipements.... de quel pilote on parle ? doit on changer le nom de nos classes ? que de questions ;-)) Bon je sais ... c'est tellement facile de trouver une parade à ce petit exemple que je n'irai pas plus loin. Simplement, la personne qui a ecrit qu'il y avait peut être un problème de sémantique a surement raison... Et je trouve que le compilateur réagit très bien : bête et méchant. C'est tout ce qu'on lui demande. On ne va pas lui demander de réfléchir à notre place non plus ??? Merci de votre attention. Bon après midi. JPBG
From: cedric.beust@beasys.com (Cedric Beust) To: <java@u-strasbg.fr> Subject: RE: Réf. : Re: bug sur les interfaces ? Date sent: Tue, 25 Jan 2000 08:47:30 -0800 Send reply to: java@u-strasbg.fr > From: jean-philippe.bret@certia.cnafmail.fr > [mailto:jean-philippe.bret@certia.cnafmail.fr] > Visiblement, il y a deux écoles dans ces > exemples : l'héritage multiple et les interfaces. Je ne suis pas d'accord avec le terme "ecole", qui sous-entend que les deux concepts sont mutuellement exclusifs. L'heritage multiple d'implementation est une chose, la programmation par interfaces en est une autre. Elles ont toutes les deux des forces et des faiblesses mais ne sont nullement exclusives. Le seul probleme, c'est qu'on ne peut pas faire d'heritage multiple d'implementation en Java et qu'il faut utiliser des moyens detournes (delegation le plus souvent). -- Cedric http://beust.com/cedric
From: cedric.beust@beasys.com (Cedric Beust) To: <java@u-strasbg.fr> Subject: RE: bug sur les interfaces ? Date sent: Tue, 25 Jan 2000 08:51:44 -0800 Send reply to: java@u-strasbg.fr > From: Rodrigo Reyes [mailto:rodrigo.reyes@lcr.thomson-csf.com] > Sent: Tuesday, January 25, 2000 2:33 AM > Rien de plus que ce qu'il dit : que la dernière version du JDE pour > Emacs (http://sunsite.auc.dk/jde) implémente également une complétion > intelligente pour les méthodes des objets. C'est à peu près équivalent à > l'intellisense qu'on trouve couramment sous windows. Es-tu sur ? Je viens de jeter un coup d'oeil rapide a la doc et je n'ai rien vu de tel. Il y a la completion pour les templates, un mode d'abreviations pour les mots-cle, mais rien sur les methodes. Tu as vu ca ou ? -- Cedric http://beust.com/cedric
From: cedric.beust@beasys.com (Cedric Beust)
To: <java@u-strasbg.fr>
Subject: RE: bug sur les interfaces ?
Date sent: Tue, 25 Jan 2000 08:57:47 -0800
Send reply to: java@u-strasbg.fr
> From: laurent8@sxb.bsf.alcatel.fr [mailto:laurent8@sxb.bsf.alcatel.fr]On
> Behalf Of Frederic LAURENT
> class ActionA implements ActionListener {
> class ActionB extends ActionA implements ActionListener {
>
> Pourquoi le compilateur ne crache-t-il pas une insulte
> quand B implémente ActionListener, puisque la classe mère
> s'en charge déjà ?
Je trouve que la redondance est plutot souhaitable en l'occurrence. Si tu
as uniquement le code de ActionB sous les yeux, le fait qu'il est un
ActionListener ne saute pas aux yeux. Si tu repetes "implements
ActionListener", c'est plus clair.
C'est un peu la meme ligne de pensee que de repeter le mot-cle "virtual"
en C++ dans la chaine d'heritage. Ca aide la relecture.
--
Cedric
http://beust.com/cedric
From: cedric.beust@beasys.com (Cedric Beust) To: <java@u-strasbg.fr> Subject: RE: bug sur les interfaces ? Date sent: Tue, 25 Jan 2000 08:59:36 -0800 Send reply to: java@u-strasbg.fr > From: desnoix@isis.u-strasbg.fr [mailto:desnoix@isis.u-strasbg.fr]On > Behalf Of Guillaume Desnoix > Forcement, le C++ ne connaissant pas la notion d'interface... Non, ca n'a rien a voir (et au passage, il y a la notion d'interface en C++). C++ ne laisse pas passer le code parce qu'il est ambigu : il y a deux fonctions m() et seul le programmeur sait laquelle il veut appeler. Dans le cas de Java, l'heritage multiple s'applique a une *interface*. Il n'y a donc aucune ambiguite et le compilateur sait comment generer l'appel. -- Cedric http://beust.com/cedric
Date sent: Tue, 25 Jan 2000 18:03:58 +0100
From: Remi Forax <forax@univ-mlv.fr>
To: java@u-strasbg.fr
Subject: Re: bug sur les interfaces ?
Send reply to: java@u-strasbg.fr
Frederic LAURENT wrote:
>
> Je vais essayer de préciser ma pensée.
> En fait, il me semble dommage que le compilateur java se
> borne (dans ce cas, au diable les généralités faciles) à
> une compilation syntaxique et non sémantique.
>
> A fournit une méthode m
> B implémente I qui demande une méthode m, et B dérive de A
> et voilà le tour est joué.
Effectivement, ici, tu as bien fourni une implementation a ton
interface donc ya pas de probleme.
Pour l'exemple en C++, il faut tester avec des virtuelles
pures pour pouvoir comparer !!!
Effectivement, les interfaces poses quelques problemes de
logique, par exemple l'interface Cloneable et Serializable
sont differentes alors qu'elles ne declarent pas de
methodes toute les deux.
Donc en plus de la notion de la notion de semantique, il y a
aussi une notion de "j'appartient a (je respecte) tel mecanisme".
..
> Je peux donner un autre exemple qui me laisse perplexe et qui
> marche parfaitement (cf source)
>
> class ActionA implements ActionListener {
> class ActionB extends ActionA implements ActionListener {
je suis un manifere et j'ai un bras gauche
je suis un homme descendant d'un manifere et j'ai un bras gauche
et ou est le probleme ??
Bon, je me moque, mais effectivement ya plein de probleme avec le
mecanisme d'interface au niveau conceptuel.
En fait, une interface definie :
- un type que l'on peut manipuler (comme le sous-typage)
- si on implemente cette interface, on definie une appartenance a
un mecanisme.
- une serie de methode a implementer (l'idee que l'interface est
une classe abstraite abstraite (ceci n'est pas une erreur de
frappe).
et je dois en oublier
>
> Pourquoi le compilateur ne crache-t-il pas une insulte
> quand B implémente ActionListener, puisque la classe mère
> s'en charge déjà ?
> Quelle est la signification de ce code ? Il est difficile
> de savoir ce que l'on veut vraiment faire, non ?
> Alors évidemment le bon sens résoud le problème, mais je
> trouve que ce n'est pas suffisant.
heu, je sais ou on se sert de cette distinction, c'est lorsqu'on
cherche pour une methode donnee a qu'elle interface elle
appartient, dans ce cas la, on prend habituellement la
premiere interface dans la liste.
dans ce cas la,
class A implements I
class B extends A implements J
est different de
class B extends A implements I,J
pratiquemenet, si on regarde le code des RMIs, ya ce genre de
manip pour generer les skeletons dynamiquement.
>
> En plus on retrouve l'instruction d'implémentation dans le
> byte code des 2 classes.
>
> voila, votre avis m'intéresse...
> Frédéric LAURENT
> mailto:frederic.laurent@sxb.bsf.alcatel.fr
> Tél : (33) 03 88 67 77 00 poste 74701
Remi Forax
From: cedric.beust@beasys.com (Cedric Beust) To: <java@u-strasbg.fr> Subject: RE: Réf. : Re: bug sur les interfaces ? Date sent: Tue, 25 Jan 2000 09:27:47 -0800 Send reply to: java@u-strasbg.fr > From: desnoix@isis.u-strasbg.fr [mailto:desnoix@isis.u-strasbg.fr]On > Behalf Of Guillaume Desnoix > Effectivement, sauf qu'en pratique il y a peu de langages qui proposent > les deux... C++. > Mais pourquoi, en pratique ;-), est-ce le cas ? Je serais vraiment > interesse par la raison. Le seul exemple qui me vient a l'esprit est > Objective-C qui propose (autant que je sache) les deux. La raison pour quoi ? (j'ai un peu perdu le fil de la discussion :-)) Objective C n'a pas d'heritage multiple d'implementation (tout comme Smalltalk). Il y a le concept d'interface, cela dit (et c'est a ma connaissance le premier langage grand public qui les a proposees). Au passage, j'ai adore Objective C, j'aurais aime qu'il s'impose. > Et inversement, en C++ on ne peut pas faire d'interfaces et on est > oblige d'utiliser des classes ;-( Tu peux faire tout ce que tu veux avec C++. Le fait qu'il n'ait pas le mot-cle "interface" est un detail syntaxique. Quelques idees sur l'eventail des possibilites : - heritages d'implementations seulement - heritages d'interfaces uniquement - melange des deux (cet idiome s'appelle "mix-in" et s'utilise en heritant "multiplement" d'une classe abstraite et une classe concrete, cette derniere implementant la premiere) Sur un plan plus general, je remarque une tendance prononcee a abuser des interfaces en Java. Beaucoup de developpeurs ne sont pas conscients des limitations et utilisent des interfaces ou` des classes abstraites auraient beaucoup plus de sens (et seraient plus faciles a faire evoluer). Mais c'est un autre debat :-) -- Cedric http://beust.com/cedric
Date sent: Tue, 25 Jan 2000 18:31:53 +0100 From: Guillaume Desnoix <guillaume-desnoix@memoire.com> To: java@u-strasbg.fr Subject: Re: Réf. : Re: bug sur les interfaces ? Send reply to: java@u-strasbg.fr > > Visiblement, il y a deux écoles dans ces > > exemples : l'héritage multiple et les interfaces. Cedric Beust wrote: > Je ne suis pas d'accord avec le terme "ecole", qui sous-entend que les > deux concepts sont mutuellement exclusifs. Effectivement, sauf qu'en pratique il y a peu de langages qui proposent les deux... > L'heritage multiple d'implementation est une chose, la programmation par > interfaces en est une autre. Elles ont toutes les deux des forces et des > faiblesses mais ne sont nullement exclusives. Mais pourquoi, en pratique ;-), est-ce le cas ? Je serais vraiment interesse par la raison. Le seul exemple qui me vient a l'esprit est Objective-C qui propose (autant que je sache) les deux. > Le seul probleme, c'est qu'on ne > peut pas faire d'heritage multiple d'implementation en Java et qu'il > faut utiliser des moyens detournes (delegation le plus souvent). Et inversement, en C++ on ne peut pas faire d'interfaces et on est oblige d'utiliser des classes ;-( Guillaume
From: cedric.beust@beasys.com (Cedric Beust)
To: <java@u-strasbg.fr>
Subject: RE: bug sur les interfaces ?
Date sent: Tue, 25 Jan 2000 09:39:30 -0800
Send reply to: java@u-strasbg.fr
> From: desnoix@isis.u-strasbg.fr [mailto:desnoix@isis.u-strasbg.fr]On
> Behalf Of Guillaume Desnoix
> Ne programmant plus en C++ depuis longtemps, j'ai peut-etre rate un
> episode. Tu peux m'envoyer un exemple d'interface en C++, STP ?
Typiquement avec des classes virtuelles pures :
class I {
public:
virtual void foo1() = 0;
virtual void foo2() = 0;
};
--
Cedric
http://beust.com/cedric
Date sent: Tue, 25 Jan 2000 18:41:16 +0100 From: Guillaume Desnoix <guillaume-desnoix@memoire.com> To: java@u-strasbg.fr Subject: Re: bug sur les interfaces ? Send reply to: java@u-strasbg.fr > > Forcement, le C++ ne connaissant pas la notion d'interface... Cedric Beust wrote: > (et au passage, il y a la notion d'interface en C++). Ne programmant plus en C++ depuis longtemps, j'ai peut-etre rate un episode. Tu peux m'envoyer un exemple d'interface en C++, STP ? > Non, ca n'a rien a voir > C++ ne laisse pas passer le code parce qu'il est ambigu : il y a deux > fonctions m() et seul le programmeur sait laquelle il veut appeler. C'est ce que j'ai dit... C'est un probleme de resolution, un probleme different de celui qui est discute ici. L'absence d'obligation de repeter les declarations de methodes de l'interface/la classe virtuelle se pose en Java _et_ en C++. > Dans le cas de Java, l'heritage multiple s'applique a une *interface*. > Il n'y a donc aucune ambiguite et le compilateur sait comment generer > l'appel. Oui. Et c'est bien la le probleme qui est discute. Il ne devrait pas savoir... (du point de vue conception). Guillaume
Date sent: Tue, 25 Jan 2000 18:56:17 +0100
From: Remi Forax <forax@univ-mlv.fr>
To: java@u-strasbg.fr
Subject: Re: Réf. : Re: bug sur les interfaces ?
Send reply to: java@u-strasbg.fr
jean-philippe.bret@certia.cnafmail.fr wrote:
>
> en réponse à Frederic Laurent :
..
>
> Je pense qu'il est normal, dans le cas de
> l'héritage multiple, de se faire jeter par le
> compilateur. Une solution (peut être possible)
> serait de faire un cast sur l'instance qui
> evoque cette méthode m(). Ainsi, on pourrait
> indiquer la méthode que l'on utilise.
>
> Ex : pour la classe X , ((X) monInstance).m()
>
> Vous noterez au passage que j'ai bien retenu
> la leçon sur le cast ;-)
Juste une precision, en C++, on peut aussi
utiliser le mot-cle using
class A
{
void m() {}
};
class B
{
void m() {}
}
class C: public A,B
{
using A::m; // hop, ici je veux celle de A
}
..
> JPBG
Remi
Date sent: Tue, 25 Jan 2000 19:22:31 +0100
From: Guillaume Desnoix <guillaume-desnoix@memoire.com>
To: java@u-strasbg.fr
Subject: Re: bug sur les interfaces ?
Send reply to: java@u-strasbg.fr
Cedric Beust wrote:
> Typiquement avec des classes virtuelles pures :
> class I {
> public:
> virtual void foo1() = 0;
> virtual void foo2() = 0;
> };
Merci pour l'exemple. C'est effectivement le moyen le plus propre de
simuler des interfaces en C++. Mais une classe virtuelle et une
interface sont deux choses differentes. Rien n'empeche d'ajouter du code a
la _classe_ I. Du point de vue de la conception, ce n'est pas acceptable.
> > Effectivement, sauf qu'en pratique il y a peu de langages qui
> > proposent les deux...
> C++.
Non. cf ci-dessus et ci-dessous puisque Objective-C n'autorise pas
l'heritage multiple.
>
> > Mais pourquoi, en pratique ;-), est-ce le cas ? Je serais vraiment
> > interesse par la raison. Le seul exemple qui me vient a l'esprit est
> > Objective-C qui propose (autant que je sache) les deux.
> Objective C n'a pas d'heritage multiple d'implementation (tout comme
> Smalltalk). Il y a le concept d'interface, cela dit (et c'est a ma
> connaissance le premier langage grand public qui les a proposees).
Dommage. Donc a l'heure actuelle il n'y a pas de langage proposant
interfaces et heritage multiple ?
> Au passage, j'ai adore Objective C, j'aurais aime qu'il s'impose.
Probleme de syntaxe... (meme raison que pour Eiffel ;-) Des que ca
s'eloigne du basic ou du C, ca ne peut pas vraiment marcher.
> > Et inversement, en C++ on ne peut pas faire d'interfaces et on est
> > oblige d'utiliser des classes ;-(
> Tu peux faire tout ce que tu veux avec C++.
Oui mais pas proprement. De meme en Java ou l'heritage multiple peut se
faire par interface/delegation. Mais dans les 2 cas, ce n'est pas
satisfaisant.
> Le fait qu'il n'ait pas le mot-cle "interface" est un detail syntaxique.
Ce n'est pas qu'un detail par ailleurs revelateur. Je peux rajouter du
code a I...
Guillaume
From: cedric.beust@beasys.com (Cedric Beust) To: <java@u-strasbg.fr> Subject: RE: bug sur les interfaces ? Date sent: Tue, 25 Jan 2000 12:52:13 -0800 Send reply to: java@u-strasbg.fr > From: desnoix@isis.u-strasbg.fr [mailto:desnoix@isis.u-strasbg.fr]On > Behalf Of Guillaume Desnoix > Merci pour l'exemple. C'est effectivement le moyen le plus propre de > simuler des interfaces en C++. Mais une classe virtuelle et une > interface sont deux choses differentes. Rien n'empeche d'ajouter du code > a la _classe_ I. Rien n'empeche non plus d'ajouter une methode a l'interface I. Et si tu ajoutes du code a une classe abstraite, ton programme continue de compiler, ce qui n'est pas vrai pour une interface. Je ne suis pas sur de te suivre, la... > Dommage. Donc a l'heure actuelle il n'y a pas de langage proposant > interfaces et heritage multiple ? C'est apparemment une question de terminologie. Pour moi, supporter la notion d'interface n'est pas une question de syntaxe mais de semantique. C++ ne possede pas le mot-cle (non supporte syntaxiquement) mais offre indubitablement la fonctionnalite par le biais des classes virtuelles pures (support semantique). > Oui mais pas proprement. De meme en Java ou l'heritage multiple peut se > faire par interface/delegation. Mais dans les 2 cas, ce n'est pas > satisfaisant. Encore une fois, que signifie "proprement" ? Pour moi, simuler l'heritage multiple d'implementation par de la delegation n'est pas "propre" : on perd le typage et on est oblige de "forwarder" a la main tout un tas de fonctions. Un cauchemar de maintenabilite... -- Cedric http://beust.com/cedric
Date sent: Thu, 27 Jan 2000 19:10:48 +0100 From: Guillaume Desnoix <guillaume-desnoix@memoire.com> To: java@u-strasbg.fr Subject: Re: bug sur les interfaces ? Send reply to: java@u-strasbg.fr > > Merci pour l'exemple. C'est effectivement le moyen le plus propre de > > simuler des interfaces en C++. Mais une classe virtuelle et une > > interface sont deux choses differentes. Rien n'empeche d'ajouter du > > code a la _classe_ I. Cedric Beust wrote: > Rien n'empeche non plus d'ajouter une methode a l'interface I. Ca doit faire longtemps que tu n'as pas programme en Java ;-)) car on ne peut pas rajouter de methode (code) a une interface... > > Et si tu ajoutes du code a une classe abstraite, ton programme > > continue de compiler, ce qui n'est pas vrai pour une interface. > Je ne suis pas sur de te suivre, la... cf ci-dessus. > > Dommage. Donc a l'heure actuelle il n'y a pas de langage proposant > > interfaces et heritage multiple ? > C'est apparemment une question de terminologie. Pour moi, supporter la > notion d'interface n'est pas une question de syntaxe mais de semantique. > C++ ne possede pas le mot-cle (non supporte syntaxiquement) mais offre > indubitablement la fonctionnalite par le biais des classes virtuelles > pures (support semantique). Bien sur. Sauf que la syntaxe n'est pas contraignante et qu'il est vite tentant de rajouter du code. D'ou des problemes (voir autre message). > > Oui mais pas proprement. De meme en Java ou l'heritage multiple peut > > se faire par interface/delegation. Mais dans les 2 cas, ce n'est pas > > satisfaisant. > Encore une fois, que signifie "proprement" ? Pour moi, simuler > l'heritage multiple d'implementation par de la delegation n'est pas > "propre" : on perd le typage et on est oblige de "forwarder" a la main > tout un tas de fonctions. Un cauchemar de maintenabilite... Exactement ce que je dis. Simuler l'heritage multiple en Java et simuler les interfaces en C++ sont deux choses non satisfaisantes. Guillaume