"Vincent" a écrit dans le message de
news:Arf! Si tu considères que les templates sont une "commodité syntaxique",
Expression un peu mal choisie je te l'accorde, ça ne rend pas bien
compte de l'utilité de la chose... Mais je continue de penser que ça
n'est pas indispensable.
C'est juste un paradigme supplémentaire (programmation générique, inspiré de
la programmation fonctionnelle). Dans le même ordre d'idée, on pourrait dire
que le paradigme OO n'est pas indispensable quoique utile.
"Vincent" <vclassine@elan.fr> a écrit dans le message de
news:9e49e584.0307282316.71796030@posting.google.com...
Arf! Si tu considères que les templates sont une "commodité syntaxique",
Expression un peu mal choisie je te l'accorde, ça ne rend pas bien
compte de l'utilité de la chose... Mais je continue de penser que ça
n'est pas indispensable.
C'est juste un paradigme supplémentaire (programmation générique, inspiré de
la programmation fonctionnelle). Dans le même ordre d'idée, on pourrait dire
que le paradigme OO n'est pas indispensable quoique utile.
"Vincent" a écrit dans le message de
news:Arf! Si tu considères que les templates sont une "commodité syntaxique",
Expression un peu mal choisie je te l'accorde, ça ne rend pas bien
compte de l'utilité de la chose... Mais je continue de penser que ça
n'est pas indispensable.
C'est juste un paradigme supplémentaire (programmation générique, inspiré de
la programmation fonctionnelle). Dans le même ordre d'idée, on pourrait dire
que le paradigme OO n'est pas indispensable quoique utile.
(Vincent) writes:
|> wrote in message
|> news:...
|> > Gabriel Dos Reis wrote in message
|> > news:...
|> > > "Arnaud Debaene" writes:
|> > > | Les templates ne servent pas qu'à faire des conteneurs de
|> > > | T, loin de là.
|> > > ah bon ?!
|> > Oui, mais comme il a dit, les templates ne sont qu'une
|> > commodité syntaxique. En fin de compte, la
|> > méta-programmation, ce n'est qu'une façon de générer
|> > du code -- tu n'as qu'à écrire ce qu'il aurait
|> > généré à la main:-).
|> > Pendant qu'on y est, on pourrait éliminer les fonctions
|> > aussi, parce qu'elles non plus elles ne sont qu'une commodité
|> > syntaxique ; on n'a qu'écrire le vrai code à leur place.
|> > C'est la dernière mode en programmation. Ça s'appelle la
|> > programmation copier/coller.
|> Je ne l'ai pas dis dans cet esprit c'est certe très utile (même si il
|> ne fauit pas exagèrer on n'écrit pas tant de templates que ça...),
Je suis contre l'exagération aussi. Surtout quand les compilateurs
ont du mal à suivre. Mais d'une part, je trouve que la commodité
syntactique n'est pas si mauvais que ça,
Entièrement d'accord, le point de vue que j'ai c'est plutôt "utile et
et d'autre, je crois que
si tu penses que les templates, ce n'est que la commodité
syntactique, je crois qu'il y a quelque chose que tu n'as pas compris.
Les templates, tels que certains les utilisent, sont
révolutionnaire. Je ne sais si les bureaux d'études sont près
pour cette révolution-là -- je crois plutôt que non, mais
c'est bien autre chose qu'une commodité syntactique. C'est
peut-être même plus que l'introduction des fonctions, pour dire
à quel point c'est autre chose. (C'est pour ça, d'ailleurs,
qu'il faut du temps avant qu'il devient une technologie courante.)
Peut-être que je n'en mesure pas toute la puissance, effectivement.
|> mais ça reste une "commodité syntaxique"... J'entends par
|> là que ça n'apporte pas de nouvelle possibilités.
Je te conseille de lire Andrei. (Gabi pourrait donner des
références exactes. J'ai un mal fou déjà avec son nom de
famille.) Qu'on soit d'accord avec ce qu'il fait ou non (et j'ai mes
doutes sur l'applicabilité dans l'industrie), ça dépasse de
loins ce que j'appellerai une commodité syntactique.
Je le note, mais franchement j'ai une étagère pleine de bouquin
|> A la limite une feignasse peut systématiquement utiliser un
|> conteneur générique configuré pour accepter des Object...
Mais est-ce que tu as compris que les templates C++, ce n'est pas que
les collections ? Les templates, c'est un langage de programmation qui
permet à définir des programmes -- un langage de
méta-programmation, en somme.
J'ai compris que ça n'est pas seulement ça. Mais dans l'ensemble il me
vclassine@elan.fr (Vincent) writes:
|> kanze@gabi-soft.fr wrote in message
|> news:<d6652001.0307290204.7eb785f4@posting.google.com>...
|> > Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message
|> > news:<m3lluixutv.fsf@uniton.integrable-solutions.net>...
|> > > "Arnaud Debaene" <adebaene@club-internet.fr> writes:
|> > > | Les templates ne servent pas qu'à faire des conteneurs de
|> > > | T, loin de là.
|> > > ah bon ?!
|> > Oui, mais comme il a dit, les templates ne sont qu'une
|> > commodité syntaxique. En fin de compte, la
|> > méta-programmation, ce n'est qu'une façon de générer
|> > du code -- tu n'as qu'à écrire ce qu'il aurait
|> > généré à la main:-).
|> > Pendant qu'on y est, on pourrait éliminer les fonctions
|> > aussi, parce qu'elles non plus elles ne sont qu'une commodité
|> > syntaxique ; on n'a qu'écrire le vrai code à leur place.
|> > C'est la dernière mode en programmation. Ça s'appelle la
|> > programmation copier/coller.
|> Je ne l'ai pas dis dans cet esprit c'est certe très utile (même si il
|> ne fauit pas exagèrer on n'écrit pas tant de templates que ça...),
Je suis contre l'exagération aussi. Surtout quand les compilateurs
ont du mal à suivre. Mais d'une part, je trouve que la commodité
syntactique n'est pas si mauvais que ça,
Entièrement d'accord, le point de vue que j'ai c'est plutôt "utile et
et d'autre, je crois que
si tu penses que les templates, ce n'est que la commodité
syntactique, je crois qu'il y a quelque chose que tu n'as pas compris.
Les templates, tels que certains les utilisent, sont
révolutionnaire. Je ne sais si les bureaux d'études sont près
pour cette révolution-là -- je crois plutôt que non, mais
c'est bien autre chose qu'une commodité syntactique. C'est
peut-être même plus que l'introduction des fonctions, pour dire
à quel point c'est autre chose. (C'est pour ça, d'ailleurs,
qu'il faut du temps avant qu'il devient une technologie courante.)
Peut-être que je n'en mesure pas toute la puissance, effectivement.
|> mais ça reste une "commodité syntaxique"... J'entends par
|> là que ça n'apporte pas de nouvelle possibilités.
Je te conseille de lire Andrei. (Gabi pourrait donner des
références exactes. J'ai un mal fou déjà avec son nom de
famille.) Qu'on soit d'accord avec ce qu'il fait ou non (et j'ai mes
doutes sur l'applicabilité dans l'industrie), ça dépasse de
loins ce que j'appellerai une commodité syntactique.
Je le note, mais franchement j'ai une étagère pleine de bouquin
|> A la limite une feignasse peut systématiquement utiliser un
|> conteneur générique configuré pour accepter des Object...
Mais est-ce que tu as compris que les templates C++, ce n'est pas que
les collections ? Les templates, c'est un langage de programmation qui
permet à définir des programmes -- un langage de
méta-programmation, en somme.
J'ai compris que ça n'est pas seulement ça. Mais dans l'ensemble il me
(Vincent) writes:
|> wrote in message
|> news:...
|> > Gabriel Dos Reis wrote in message
|> > news:...
|> > > "Arnaud Debaene" writes:
|> > > | Les templates ne servent pas qu'à faire des conteneurs de
|> > > | T, loin de là.
|> > > ah bon ?!
|> > Oui, mais comme il a dit, les templates ne sont qu'une
|> > commodité syntaxique. En fin de compte, la
|> > méta-programmation, ce n'est qu'une façon de générer
|> > du code -- tu n'as qu'à écrire ce qu'il aurait
|> > généré à la main:-).
|> > Pendant qu'on y est, on pourrait éliminer les fonctions
|> > aussi, parce qu'elles non plus elles ne sont qu'une commodité
|> > syntaxique ; on n'a qu'écrire le vrai code à leur place.
|> > C'est la dernière mode en programmation. Ça s'appelle la
|> > programmation copier/coller.
|> Je ne l'ai pas dis dans cet esprit c'est certe très utile (même si il
|> ne fauit pas exagèrer on n'écrit pas tant de templates que ça...),
Je suis contre l'exagération aussi. Surtout quand les compilateurs
ont du mal à suivre. Mais d'une part, je trouve que la commodité
syntactique n'est pas si mauvais que ça,
Entièrement d'accord, le point de vue que j'ai c'est plutôt "utile et
et d'autre, je crois que
si tu penses que les templates, ce n'est que la commodité
syntactique, je crois qu'il y a quelque chose que tu n'as pas compris.
Les templates, tels que certains les utilisent, sont
révolutionnaire. Je ne sais si les bureaux d'études sont près
pour cette révolution-là -- je crois plutôt que non, mais
c'est bien autre chose qu'une commodité syntactique. C'est
peut-être même plus que l'introduction des fonctions, pour dire
à quel point c'est autre chose. (C'est pour ça, d'ailleurs,
qu'il faut du temps avant qu'il devient une technologie courante.)
Peut-être que je n'en mesure pas toute la puissance, effectivement.
|> mais ça reste une "commodité syntaxique"... J'entends par
|> là que ça n'apporte pas de nouvelle possibilités.
Je te conseille de lire Andrei. (Gabi pourrait donner des
références exactes. J'ai un mal fou déjà avec son nom de
famille.) Qu'on soit d'accord avec ce qu'il fait ou non (et j'ai mes
doutes sur l'applicabilité dans l'industrie), ça dépasse de
loins ce que j'appellerai une commodité syntactique.
Je le note, mais franchement j'ai une étagère pleine de bouquin
|> A la limite une feignasse peut systématiquement utiliser un
|> conteneur générique configuré pour accepter des Object...
Mais est-ce que tu as compris que les templates C++, ce n'est pas que
les collections ? Les templates, c'est un langage de programmation qui
permet à définir des programmes -- un langage de
méta-programmation, en somme.
J'ai compris que ça n'est pas seulement ça. Mais dans l'ensemble il me
writes:
| David, c'est l'expertise sans égale de toutes les détails des
| templates
Non, là tu es en train de parler John Spicer :-)
Demande à David si tu ne me crois pas.
kanze@gabi-soft.fr writes:
| David, c'est l'expertise sans égale de toutes les détails des
| templates
Non, là tu es en train de parler John Spicer :-)
Demande à David si tu ne me crois pas.
writes:
| David, c'est l'expertise sans égale de toutes les détails des
| templates
Non, là tu es en train de parler John Spicer :-)
Demande à David si tu ne me crois pas.
"Christophe Lephay" writes:"Jean-Marc Bourguet" a écrit dans le message de
news:writes:Non. C'est David Vandervoorde. (Dans les groupes anglophones, il
écrit son nom Daveed, pour qu'on le prononce correctement. Il
est belge, et malgré son nom de famille, belge francophone.)
Pourquoi "malgré" ?
Parce que Vandervoorde fait plus flamand que wallon...
L'origine, oui. Mais il faut ne pas avoir vecu longtemps en Belgique
pour faire des hypotheses sur la langue maternelle de quelqu'un en se
basant sur le nom.
"Christophe Lephay" <christophe-lephay@wanadoo.fr> writes:
"Jean-Marc Bourguet" <jm@bourguet.org> a écrit dans le message de
news:pxbfzkoz1wa.fsf@news.bourguet.org...
kanze@gabi-soft.fr writes:
Non. C'est David Vandervoorde. (Dans les groupes anglophones, il
écrit son nom Daveed, pour qu'on le prononce correctement. Il
est belge, et malgré son nom de famille, belge francophone.)
Pourquoi "malgré" ?
Parce que Vandervoorde fait plus flamand que wallon...
L'origine, oui. Mais il faut ne pas avoir vecu longtemps en Belgique
pour faire des hypotheses sur la langue maternelle de quelqu'un en se
basant sur le nom.
"Christophe Lephay" writes:"Jean-Marc Bourguet" a écrit dans le message de
news:writes:Non. C'est David Vandervoorde. (Dans les groupes anglophones, il
écrit son nom Daveed, pour qu'on le prononce correctement. Il
est belge, et malgré son nom de famille, belge francophone.)
Pourquoi "malgré" ?
Parce que Vandervoorde fait plus flamand que wallon...
L'origine, oui. Mais il faut ne pas avoir vecu longtemps en Belgique
pour faire des hypotheses sur la langue maternelle de quelqu'un en se
basant sur le nom.
On 28 Jul 2003 08:19:12 -0700, (Vincent) wrote:mais honn?tement peu d'entreprises
peuvent se permettre de maintenir une biblioth?que que leurs auteurs
aurait abandonn?...
Certes, mais une biblioth?que abandonn?e mais en open source a plus de
chances d'?tre reprise par quelqu'un d'autre...
On 28 Jul 2003 08:19:12 -0700, vclassine@elan.fr (Vincent) wrote:
mais honn?tement peu d'entreprises
peuvent se permettre de maintenir une biblioth?que que leurs auteurs
aurait abandonn?...
Certes, mais une biblioth?que abandonn?e mais en open source a plus de
chances d'?tre reprise par quelqu'un d'autre...
On 28 Jul 2003 08:19:12 -0700, (Vincent) wrote:mais honn?tement peu d'entreprises
peuvent se permettre de maintenir une biblioth?que que leurs auteurs
aurait abandonn?...
Certes, mais une biblioth?que abandonn?e mais en open source a plus de
chances d'?tre reprise par quelqu'un d'autre...
"Vincent" a écrit dans le message de
news:total = prixHorsTaxe.applyTaxe(tva);
Est tout à fait acceptable et applyTaxe n'est guère plus long à écrire
que la surcharge de l'opérateur. Même si l'opérateur peut être employé
ailleurs...
Alors, il faut que tu introduit une classe supplémentaire
Pour surcharger l'opérateur plus il te faut bien aussi une classe Prix
ou un truc dans ce goût là, non?
Non. tu peux avoir juste une classe prix qui gère ces opérations. Avec ton
exemple, tu risque de multiplier et les classes (pour les prix hors taxes,
les prix ttc, les prix auxquels la tva ne s'appliquent pas).
Là clairement c'est une discussion dans le vide, pour se rendre compte
-- une valeur
décimale qui connaît la TVA française.
Dans l'exemple C++ comme Java la TVA est dans l'appel, mais ça n'est
pas forcément une bonne idée...
Mais ce n'était qu'un exemple simple. Que faire dans les programmes du
marché, par exemple, où les formules qu'on manipule sont vraiment
compliqués, et qu'ils changent assez souvent.
Je ne vois pas l'avantage d'un opérateur par rapport à une fonction
pour l'évolutivité.
Je suis assez d'accord...Très clairement soit c'est simple ou très peu
usagé et utiliser add() ou mult() est un peu plus pénible, mais pas
bloquant. Sois c'est compliqué et il y a intérêt à encapsuler dans une
fonction, ne serait-ce que pour l'évolutivité du code... Je ne crois
pas que le fait que la surcharge d'opérateur permette d'écrire des
formules complexe et volatile en dehors d'une encapsulation soit un
atout...
L'intéret des opérateurs sur les fonctions devient évident lorsque les
formules deviennent complexes. Par exemple comprendre un calcul
d'amortissement dégressif ou de coefficient de corrélation sera plus facile
avec des opérateurs surchargés qu'avec des fonctions...
A mon avis le problème n'est pas tellement pour un calcul très
"Vincent" <vclassine@elan.fr> a écrit dans le message de
news:9e49e584.0307300124.553dbdc3@posting.google.com...
total = prixHorsTaxe.applyTaxe(tva);
Est tout à fait acceptable et applyTaxe n'est guère plus long à écrire
que la surcharge de l'opérateur. Même si l'opérateur peut être employé
ailleurs...
Alors, il faut que tu introduit une classe supplémentaire
Pour surcharger l'opérateur plus il te faut bien aussi une classe Prix
ou un truc dans ce goût là, non?
Non. tu peux avoir juste une classe prix qui gère ces opérations. Avec ton
exemple, tu risque de multiplier et les classes (pour les prix hors taxes,
les prix ttc, les prix auxquels la tva ne s'appliquent pas).
Là clairement c'est une discussion dans le vide, pour se rendre compte
-- une valeur
décimale qui connaît la TVA française.
Dans l'exemple C++ comme Java la TVA est dans l'appel, mais ça n'est
pas forcément une bonne idée...
Mais ce n'était qu'un exemple simple. Que faire dans les programmes du
marché, par exemple, où les formules qu'on manipule sont vraiment
compliqués, et qu'ils changent assez souvent.
Je ne vois pas l'avantage d'un opérateur par rapport à une fonction
pour l'évolutivité.
Je suis assez d'accord...
Très clairement soit c'est simple ou très peu
usagé et utiliser add() ou mult() est un peu plus pénible, mais pas
bloquant. Sois c'est compliqué et il y a intérêt à encapsuler dans une
fonction, ne serait-ce que pour l'évolutivité du code... Je ne crois
pas que le fait que la surcharge d'opérateur permette d'écrire des
formules complexe et volatile en dehors d'une encapsulation soit un
atout...
L'intéret des opérateurs sur les fonctions devient évident lorsque les
formules deviennent complexes. Par exemple comprendre un calcul
d'amortissement dégressif ou de coefficient de corrélation sera plus facile
avec des opérateurs surchargés qu'avec des fonctions...
A mon avis le problème n'est pas tellement pour un calcul très
"Vincent" a écrit dans le message de
news:total = prixHorsTaxe.applyTaxe(tva);
Est tout à fait acceptable et applyTaxe n'est guère plus long à écrire
que la surcharge de l'opérateur. Même si l'opérateur peut être employé
ailleurs...
Alors, il faut que tu introduit une classe supplémentaire
Pour surcharger l'opérateur plus il te faut bien aussi une classe Prix
ou un truc dans ce goût là, non?
Non. tu peux avoir juste une classe prix qui gère ces opérations. Avec ton
exemple, tu risque de multiplier et les classes (pour les prix hors taxes,
les prix ttc, les prix auxquels la tva ne s'appliquent pas).
Là clairement c'est une discussion dans le vide, pour se rendre compte
-- une valeur
décimale qui connaît la TVA française.
Dans l'exemple C++ comme Java la TVA est dans l'appel, mais ça n'est
pas forcément une bonne idée...
Mais ce n'était qu'un exemple simple. Que faire dans les programmes du
marché, par exemple, où les formules qu'on manipule sont vraiment
compliqués, et qu'ils changent assez souvent.
Je ne vois pas l'avantage d'un opérateur par rapport à une fonction
pour l'évolutivité.
Je suis assez d'accord...Très clairement soit c'est simple ou très peu
usagé et utiliser add() ou mult() est un peu plus pénible, mais pas
bloquant. Sois c'est compliqué et il y a intérêt à encapsuler dans une
fonction, ne serait-ce que pour l'évolutivité du code... Je ne crois
pas que le fait que la surcharge d'opérateur permette d'écrire des
formules complexe et volatile en dehors d'une encapsulation soit un
atout...
L'intéret des opérateurs sur les fonctions devient évident lorsque les
formules deviennent complexes. Par exemple comprendre un calcul
d'amortissement dégressif ou de coefficient de corrélation sera plus facile
avec des opérateurs surchargés qu'avec des fonctions...
A mon avis le problème n'est pas tellement pour un calcul très
Vincent wrote:Euh? En C++ on peut écrire une fonction redéfinissable mais pas
appelable par la classe fille?
Oui.
class A
{
private:
virtual void f();
};
f est redéfinissable, mais non appelable, ni par le client, ni par la
classe fille.
Vincent wrote:
Euh? En C++ on peut écrire une fonction redéfinissable mais pas
appelable par la classe fille?
Oui.
class A
{
private:
virtual void f();
};
f est redéfinissable, mais non appelable, ni par le client, ni par la
classe fille.
Vincent wrote:Euh? En C++ on peut écrire une fonction redéfinissable mais pas
appelable par la classe fille?
Oui.
class A
{
private:
virtual void f();
};
f est redéfinissable, mais non appelable, ni par le client, ni par la
classe fille.
je suis en pleine lecture du livre de Bertrand Meyer et le chapitre est
encore tout chaud dans ma tête,
ce qui me gène dans ta proposition pour "implémenter" le contrat, c'est
l'impact sur les performances.
En effet, le contrat doit permettre de nous passer d'un certain nombre de
test pour éviter notamment
la redondance de code, toute fois il est important de pouvoir garantir le
contrat en fournissant des
assertions lors de la phase de débuggage, pour pouvoir dire "tiens mon
client n'a pas respecter le contrat
c'est de sa faute si le résultat est inattendue...."
Une fois que l'on passe en mode de production, une majorité ou la totalité
des assertions sont supprimer.
car on sait que les client qui ont appeler les méthodes ont pris soin de
respecter les préconditions. Et que
mes méthodes semble fournir les résultats escompté (post-conditions).
Quelle solution as-tu en Java pour en mode "release" supprimer les appels a
tes fonction pre_condition et
post_condition, qui ne devrait plus être nécessaire après avoir effectuer le
debuggage?
Je reprenais un exemple avec des fonctions, les assertions éxistent
je suis en pleine lecture du livre de Bertrand Meyer et le chapitre est
encore tout chaud dans ma tête,
ce qui me gène dans ta proposition pour "implémenter" le contrat, c'est
l'impact sur les performances.
En effet, le contrat doit permettre de nous passer d'un certain nombre de
test pour éviter notamment
la redondance de code, toute fois il est important de pouvoir garantir le
contrat en fournissant des
assertions lors de la phase de débuggage, pour pouvoir dire "tiens mon
client n'a pas respecter le contrat
c'est de sa faute si le résultat est inattendue...."
Une fois que l'on passe en mode de production, une majorité ou la totalité
des assertions sont supprimer.
car on sait que les client qui ont appeler les méthodes ont pris soin de
respecter les préconditions. Et que
mes méthodes semble fournir les résultats escompté (post-conditions).
Quelle solution as-tu en Java pour en mode "release" supprimer les appels a
tes fonction pre_condition et
post_condition, qui ne devrait plus être nécessaire après avoir effectuer le
debuggage?
Je reprenais un exemple avec des fonctions, les assertions éxistent
je suis en pleine lecture du livre de Bertrand Meyer et le chapitre est
encore tout chaud dans ma tête,
ce qui me gène dans ta proposition pour "implémenter" le contrat, c'est
l'impact sur les performances.
En effet, le contrat doit permettre de nous passer d'un certain nombre de
test pour éviter notamment
la redondance de code, toute fois il est important de pouvoir garantir le
contrat en fournissant des
assertions lors de la phase de débuggage, pour pouvoir dire "tiens mon
client n'a pas respecter le contrat
c'est de sa faute si le résultat est inattendue...."
Une fois que l'on passe en mode de production, une majorité ou la totalité
des assertions sont supprimer.
car on sait que les client qui ont appeler les méthodes ont pris soin de
respecter les préconditions. Et que
mes méthodes semble fournir les résultats escompté (post-conditions).
Quelle solution as-tu en Java pour en mode "release" supprimer les appels a
tes fonction pre_condition et
post_condition, qui ne devrait plus être nécessaire après avoir effectuer le
debuggage?
Je reprenais un exemple avec des fonctions, les assertions éxistent
Loïc Joly wrote in message news:<bg5tvk$oj8$...Vincent wrote:Euh? En C++ on peut écrire une fonction redéfinissable mais pas
appelable par la classe fille?
Oui.
class A
{
private:
virtual void f();
};
f est redéfinissable, mais non appelable, ni par le client, ni par la
classe fille.
Et on n'est pas obligé de la redéfinir pour créer une classe concrète fille, non?
Loïc Joly <loic.actarus.joly@wanadoo.fr> wrote in message news:<bg5tvk$oj8$1@news-reader4.wanadoo.fr>...
Vincent wrote:
Euh? En C++ on peut écrire une fonction redéfinissable mais pas
appelable par la classe fille?
Oui.
class A
{
private:
virtual void f();
};
f est redéfinissable, mais non appelable, ni par le client, ni par la
classe fille.
Et on n'est pas obligé de la redéfinir pour créer une classe concrète fille, non?
Loïc Joly wrote in message news:<bg5tvk$oj8$...Vincent wrote:Euh? En C++ on peut écrire une fonction redéfinissable mais pas
appelable par la classe fille?
Oui.
class A
{
private:
virtual void f();
};
f est redéfinissable, mais non appelable, ni par le client, ni par la
classe fille.
Et on n'est pas obligé de la redéfinir pour créer une classe concrète fille, non?
