Ça c'est l'héritage et l'overloading, que je sache tous les langages OO le permettent :)
Non, non. L'héritage permet de créer une _nouvelle_ classe avec les nouvelles méthodes, pas d'ajouter les méthodes à la classe elle-même.
Je prends un exemple concret :
Tu as une classe XML::DOM::Node qui sert à représenter quelque chose, peu importe quoi. Tu veux lui ajouter une méthode xql pour faire des recherches. Avec un modèle orienté objets du style de celui de java, tu vas créer une classe dérivée XML::DOM::Node::XQL (par exemple) avec cette méthode. Maintenant, tu as un module SpSVG qui sert d'interaction avec Inkscape, et qui te fournit l'arbre XML à manipuler, sous forme de XML::DOM::Node. Tu l'as dans l'os : ce sont des XML::DOM::Node, pas des XML::DOM::Node::XQL, et ta classe dérivée ne te sert à rien.
Avec le système d'objets de Perl, le module XML::XQL::DOM vient ajouter la méthode xql directement dans la classe XML::DOM::Node, et toutes les instances de cette classe en profitent.
Emmanuel Florac wrote in message
<pan.2006.02.17.08.44.54.937039@imaginet.fr>:
Ça c'est l'héritage et l'overloading, que je sache tous les langages
OO le permettent :)
Non, non. L'héritage permet de créer une _nouvelle_ classe avec les
nouvelles méthodes, pas d'ajouter les méthodes à la classe elle-même.
Je prends un exemple concret :
Tu as une classe XML::DOM::Node qui sert à représenter quelque chose, peu
importe quoi. Tu veux lui ajouter une méthode xql pour faire des recherches.
Avec un modèle orienté objets du style de celui de java, tu vas créer une
classe dérivée XML::DOM::Node::XQL (par exemple) avec cette méthode.
Maintenant, tu as un module SpSVG qui sert d'interaction avec Inkscape, et
qui te fournit l'arbre XML à manipuler, sous forme de XML::DOM::Node. Tu
l'as dans l'os : ce sont des XML::DOM::Node, pas des XML::DOM::Node::XQL, et
ta classe dérivée ne te sert à rien.
Avec le système d'objets de Perl, le module XML::XQL::DOM vient ajouter la
méthode xql directement dans la classe XML::DOM::Node, et toutes les
instances de cette classe en profitent.
Ça c'est l'héritage et l'overloading, que je sache tous les langages OO le permettent :)
Non, non. L'héritage permet de créer une _nouvelle_ classe avec les nouvelles méthodes, pas d'ajouter les méthodes à la classe elle-même.
Je prends un exemple concret :
Tu as une classe XML::DOM::Node qui sert à représenter quelque chose, peu importe quoi. Tu veux lui ajouter une méthode xql pour faire des recherches. Avec un modèle orienté objets du style de celui de java, tu vas créer une classe dérivée XML::DOM::Node::XQL (par exemple) avec cette méthode. Maintenant, tu as un module SpSVG qui sert d'interaction avec Inkscape, et qui te fournit l'arbre XML à manipuler, sous forme de XML::DOM::Node. Tu l'as dans l'os : ce sont des XML::DOM::Node, pas des XML::DOM::Node::XQL, et ta classe dérivée ne te sert à rien.
Avec le système d'objets de Perl, le module XML::XQL::DOM vient ajouter la méthode xql directement dans la classe XML::DOM::Node, et toutes les instances de cette classe en profitent.
Paul Gaborit
À (at) Fri, 17 Feb 2006 09:44:55 +0100, Emmanuel Florac écrivait (wrote):
Le Fri, 17 Feb 2006 00:34:23 +0000, Nicolas George a écrit :
Le plus agréable, je trouve, et qui manque à peu près partout aill eurs (il paraît que javascript a vaguement la même possibilité, mais je n'a i pas vérifié), c'est qu'un module puisse ajouter des méthodes à une c lasse existante.
Ça c'est l'héritage et l'overloading, que je sache tous les langages OO le permettent :)
L'héritage consiste à créer une classe qui hérite d'une autre classe et donc des méthodes de cette autre classe.
L'overloading permet de surdéfinir une méthode héritée ou de surdéfinir l'usage des opérateurs.
Mais ce dont parle Nicolas George, c'est la possibilité d'ajouter ou de redéfinir une méthode directement dans une classe existante depuis l'extérieur et sans passer par de l'héritage.
C'est effectivement très pratique et puissant mais ça fait peur aux programmeurs qui ont appris la POO sur d'autres langages.
En fait, la protection du code, des attributs, etc. est un contrat. Dans la plupart des langages, c'est le compilateur qui l'assure. En Perl, c'est le programmeur qui le respecte (ou non).
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Fri, 17 Feb 2006 09:44:55 +0100,
Emmanuel Florac <eflorac@imaginet.fr> écrivait (wrote):
Le Fri, 17 Feb 2006 00:34:23 +0000, Nicolas George a écrit :
Le plus agréable, je trouve, et qui manque à peu près partout aill eurs (il
paraît que javascript a vaguement la même possibilité, mais je n'a i pas
vérifié), c'est qu'un module puisse ajouter des méthodes à une c lasse
existante.
Ça c'est l'héritage et l'overloading, que je sache tous les langages
OO le permettent :)
L'héritage consiste à créer une classe qui hérite d'une autre classe
et donc des méthodes de cette autre classe.
L'overloading permet de surdéfinir une méthode héritée ou de
surdéfinir l'usage des opérateurs.
Mais ce dont parle Nicolas George, c'est la possibilité d'ajouter ou
de redéfinir une méthode directement dans une classe existante depuis
l'extérieur et sans passer par de l'héritage.
C'est effectivement très pratique et puissant mais ça fait peur aux
programmeurs qui ont appris la POO sur d'autres langages.
En fait, la protection du code, des attributs, etc. est un
contrat. Dans la plupart des langages, c'est le compilateur qui
l'assure. En Perl, c'est le programmeur qui le respecte (ou non).
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Fri, 17 Feb 2006 09:44:55 +0100, Emmanuel Florac écrivait (wrote):
Le Fri, 17 Feb 2006 00:34:23 +0000, Nicolas George a écrit :
Le plus agréable, je trouve, et qui manque à peu près partout aill eurs (il paraît que javascript a vaguement la même possibilité, mais je n'a i pas vérifié), c'est qu'un module puisse ajouter des méthodes à une c lasse existante.
Ça c'est l'héritage et l'overloading, que je sache tous les langages OO le permettent :)
L'héritage consiste à créer une classe qui hérite d'une autre classe et donc des méthodes de cette autre classe.
L'overloading permet de surdéfinir une méthode héritée ou de surdéfinir l'usage des opérateurs.
Mais ce dont parle Nicolas George, c'est la possibilité d'ajouter ou de redéfinir une méthode directement dans une classe existante depuis l'extérieur et sans passer par de l'héritage.
C'est effectivement très pratique et puissant mais ça fait peur aux programmeurs qui ont appris la POO sur d'autres langages.
En fait, la protection du code, des attributs, etc. est un contrat. Dans la plupart des langages, c'est le compilateur qui l'assure. En Perl, c'est le programmeur qui le respecte (ou non).
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Eric Jacoboni
Nicolas George <nicolas$ writes:
Avec le système d'objets de Perl, le module XML::XQL::DOM vient ajouter la méthode xql directement dans la classe XML::DOM::Node, et toutes les instances de cette classe en profitent.
Ce genre de manip est possible avec tous les langages de scripts OO, je pense. Je ne connais pas suffisamment Python sur ce point mais, en Ruby, ça donne ça (la classe String est une classe prédéfinie du langage) :
class String def remplace_a_par_i self.gsub!("a","i") end end => nil
"abracadabra".remplace_a_par_i => "ibricidibri"
Et hop, tous les objets chaînes disposent désormais de cette méthode fondamentale ! -- Eric Jacoboni, ne il y a 1443644961 secondes
Nicolas George <nicolas$george@salle-s.org> writes:
Avec le système d'objets de Perl, le module XML::XQL::DOM vient ajouter la
méthode xql directement dans la classe XML::DOM::Node, et toutes les
instances de cette classe en profitent.
Ce genre de manip est possible avec tous les langages de scripts OO,
je pense. Je ne connais pas suffisamment Python sur ce point mais, en
Ruby, ça donne ça (la classe String est une classe prédéfinie du
langage) :
class String
def remplace_a_par_i
self.gsub!("a","i")
end
end
=> nil
"abracadabra".remplace_a_par_i
=> "ibricidibri"
Et hop, tous les objets chaînes disposent désormais de cette méthode
fondamentale !
--
Eric Jacoboni, ne il y a 1443644961 secondes
Avec le système d'objets de Perl, le module XML::XQL::DOM vient ajouter la méthode xql directement dans la classe XML::DOM::Node, et toutes les instances de cette classe en profitent.
Ce genre de manip est possible avec tous les langages de scripts OO, je pense. Je ne connais pas suffisamment Python sur ce point mais, en Ruby, ça donne ça (la classe String est une classe prédéfinie du langage) :
class String def remplace_a_par_i self.gsub!("a","i") end end => nil
"abracadabra".remplace_a_par_i => "ibricidibri"
Et hop, tous les objets chaînes disposent désormais de cette méthode fondamentale ! -- Eric Jacoboni, ne il y a 1443644961 secondes
Eric Jacoboni
Emmanuel Florac writes:
Ça c'est l'héritage et l'overloading, que je sache tous les langages OO le permettent :)
<div class="anti_diptères"> overriding, pas overloading... L'overloading (surcharge) n'a rien à voir avec la POO, l'overriding (redéfinition) si... bien qu'il soit également vrai que les langages OO permettent tous, à ma connaissance, une certaine forme de surcharge.
Je dis ça, par ce que ça m'énerve de voir dans certains bouquins "override" traduit par "surcharge" : ce sont deux concepts différents. </div>
-- Eric Jacoboni, ne il y a 1443645641 secondes
Emmanuel Florac <eflorac@imaginet.fr> writes:
Ça c'est l'héritage et l'overloading, que je sache tous les langages
OO le permettent :)
<div class="anti_diptères">
overriding, pas overloading...
L'overloading (surcharge) n'a rien à voir avec la POO, l'overriding
(redéfinition) si... bien qu'il soit également vrai que les langages
OO permettent tous, à ma connaissance, une certaine forme de
surcharge.
Je dis ça, par ce que ça m'énerve de voir dans certains bouquins
"override" traduit par "surcharge" : ce sont deux concepts
différents.
</div>
Ça c'est l'héritage et l'overloading, que je sache tous les langages OO le permettent :)
<div class="anti_diptères"> overriding, pas overloading... L'overloading (surcharge) n'a rien à voir avec la POO, l'overriding (redéfinition) si... bien qu'il soit également vrai que les langages OO permettent tous, à ma connaissance, une certaine forme de surcharge.
Je dis ça, par ce que ça m'énerve de voir dans certains bouquins "override" traduit par "surcharge" : ce sont deux concepts différents. </div>
-- Eric Jacoboni, ne il y a 1443645641 secondes
Emmanuel Florac
Le Fri, 17 Feb 2006 14:05:36 +0100, Paul Gaborit a écrit :
Mais ce dont parle Nicolas George, c'est la possibilité d'ajouter ou de redéfinir une méthode directement dans une classe existante depuis l'extérieur et sans passer par de l'héritage.
Oui, je vois. Note que je ne vois pas comment on fait pour autant pour intégrer des trucs dans le namespace d'un package à partir d'un autre package, tu peux m'expliquer ?
-- Ne pas savoir de quoi on parle est un avantage dont il ne faut pas abuser. R.Debray
Le Fri, 17 Feb 2006 14:05:36 +0100, Paul Gaborit a écrit :
Mais ce dont parle Nicolas George, c'est la possibilité d'ajouter ou
de redéfinir une méthode directement dans une classe existante depuis
l'extérieur et sans passer par de l'héritage.
Oui, je vois. Note que je ne vois pas comment on fait pour autant pour
intégrer des trucs dans le namespace d'un package à partir d'un autre
package, tu peux m'expliquer ?
--
Ne pas savoir de quoi on parle est un avantage dont il ne faut pas
abuser.
R.Debray
Le Fri, 17 Feb 2006 14:05:36 +0100, Paul Gaborit a écrit :
Mais ce dont parle Nicolas George, c'est la possibilité d'ajouter ou de redéfinir une méthode directement dans une classe existante depuis l'extérieur et sans passer par de l'héritage.
Oui, je vois. Note que je ne vois pas comment on fait pour autant pour intégrer des trucs dans le namespace d'un package à partir d'un autre package, tu peux m'expliquer ?
-- Ne pas savoir de quoi on parle est un avantage dont il ne faut pas abuser. R.Debray
Emmanuel Florac
Le Fri, 17 Feb 2006 20:44:12 +0100, Eric Jacoboni a écrit :
Je dis ça, par ce que ça m'énerve de voir dans certains bouquins "override" traduit par "surcharge" : ce sont deux concepts différents.
Il faudra que tu m'expliques la différence :)
-- Le commissaire : Comment vous appelez-vous? Garance : Moi je ne m'appelle jamais, je suis toujours là. J'ai pas besoin de m'appeler. Mais les autres m'appellent Garance, si ça peut vous intéresser. Prévert,"les enfants du Paradis".
Le Fri, 17 Feb 2006 20:44:12 +0100, Eric Jacoboni a écrit :
Je dis ça, par ce que ça m'énerve de voir dans certains bouquins
"override" traduit par "surcharge" : ce sont deux concepts
différents.
Il faudra que tu m'expliques la différence :)
--
Le commissaire : Comment vous appelez-vous?
Garance : Moi je ne m'appelle jamais, je suis toujours là. J'ai pas
besoin de m'appeler. Mais les autres m'appellent Garance, si ça peut
vous intéresser.
Prévert,"les enfants du Paradis".
Le Fri, 17 Feb 2006 20:44:12 +0100, Eric Jacoboni a écrit :
Je dis ça, par ce que ça m'énerve de voir dans certains bouquins "override" traduit par "surcharge" : ce sont deux concepts différents.
Il faudra que tu m'expliques la différence :)
-- Le commissaire : Comment vous appelez-vous? Garance : Moi je ne m'appelle jamais, je suis toujours là. J'ai pas besoin de m'appeler. Mais les autres m'appellent Garance, si ça peut vous intéresser. Prévert,"les enfants du Paradis".
nospam
Chris wrote:
Question d'ailleurs existe t il d'autres langages ayant cette "particularité" ?
Un paquet :) ruby ou php par exemple permettent cela
-- Romuald Brunet, ICQ 33033393
Remplacez nospam par mon prénom pour me contacter par email
Chris <chris@sra.fr> wrote:
Question d'ailleurs existe t il d'autres langages ayant cette
"particularité" ?
Un paquet :) ruby ou php par exemple permettent cela
--
Romuald Brunet, ICQ 33033393
Remplacez nospam par mon prénom pour me contacter par email
Question d'ailleurs existe t il d'autres langages ayant cette "particularité" ?
Un paquet :) ruby ou php par exemple permettent cela
-- Romuald Brunet, ICQ 33033393
Remplacez nospam par mon prénom pour me contacter par email
Eric Jacoboni
Emmanuel Florac writes:
Il faudra que tu m'expliques la différence :)
C'est simple...
La surcharge, c'est la possibilité d'avoir deux sous-programmes portant le même nom (certains langages permettent aussi de surcharger les opérateurs prédéfinis). En 1983, Ada le permettait déjà.
Quand on utilise un langage OO, la surcharge c'est donc la possibilité d'avoir deux méthodes *d'une même classe* portant le même nom (utilisation fréquente pour les constructeurs, notamment).
La redéfinition, c'est le fait qu'une classe fille redéfinit une méthode de sa classe mère : la classe fille a donc une méthode portant le même nom que sa classe mère. C'est cette méthode qui sera appelée dans un contexte de méthode virtuelle (C++) ou non final (Java). Exemple classique : la méthode toString() en Java est redéfinie par toutes les classes qui veulent produire une représentation chaîne. Si elles ne le font pas, c'est le toString() de leur classe mère qui est utilisée, et ça remonte jusqu'à la classe racine, Object.
En Ruby, on ne peut pas surcharger une méthode, mais comme il y a les paramètres avec valeurs par défaut et les varargs on s'en passe. En Java, il n'y a pas les paramètres avec valeurs par défaut, donc on surcharge souvent. En C++ et en Ada, on a les deux.
-- Eric Jacoboni, ne il y a 1443659076 secondes
Emmanuel Florac <eflorac@imaginet.fr> writes:
Il faudra que tu m'expliques la différence :)
C'est simple...
La surcharge, c'est la possibilité d'avoir deux sous-programmes
portant le même nom (certains langages permettent aussi de surcharger
les opérateurs prédéfinis). En 1983, Ada le permettait déjà.
Quand on utilise un langage OO, la surcharge c'est donc la possibilité
d'avoir deux méthodes *d'une même classe* portant le même nom
(utilisation fréquente pour les constructeurs, notamment).
La redéfinition, c'est le fait qu'une classe fille redéfinit une
méthode de sa classe mère : la classe fille a donc une méthode portant
le même nom que sa classe mère. C'est cette méthode qui sera appelée
dans un contexte de méthode virtuelle (C++) ou non final
(Java). Exemple classique : la méthode toString() en Java est redéfinie
par toutes les classes qui veulent produire une représentation
chaîne. Si elles ne le font pas, c'est le toString() de leur classe
mère qui est utilisée, et ça remonte jusqu'à la classe racine, Object.
En Ruby, on ne peut pas surcharger une méthode, mais comme il y a les
paramètres avec valeurs par défaut et les varargs on s'en passe. En
Java, il n'y a pas les paramètres avec valeurs par défaut, donc on
surcharge souvent. En C++ et en Ada, on a les deux.
La surcharge, c'est la possibilité d'avoir deux sous-programmes portant le même nom (certains langages permettent aussi de surcharger les opérateurs prédéfinis). En 1983, Ada le permettait déjà.
Quand on utilise un langage OO, la surcharge c'est donc la possibilité d'avoir deux méthodes *d'une même classe* portant le même nom (utilisation fréquente pour les constructeurs, notamment).
La redéfinition, c'est le fait qu'une classe fille redéfinit une méthode de sa classe mère : la classe fille a donc une méthode portant le même nom que sa classe mère. C'est cette méthode qui sera appelée dans un contexte de méthode virtuelle (C++) ou non final (Java). Exemple classique : la méthode toString() en Java est redéfinie par toutes les classes qui veulent produire une représentation chaîne. Si elles ne le font pas, c'est le toString() de leur classe mère qui est utilisée, et ça remonte jusqu'à la classe racine, Object.
En Ruby, on ne peut pas surcharger une méthode, mais comme il y a les paramètres avec valeurs par défaut et les varargs on s'en passe. En Java, il n'y a pas les paramètres avec valeurs par défaut, donc on surcharge souvent. En C++ et en Ada, on a les deux.
-- Eric Jacoboni, ne il y a 1443659076 secondes
Nicolas George
Emmanuel Florac wrote in message :
Oui, je vois. Note que je ne vois pas comment on fait pour autant pour intégrer des trucs dans le namespace d'un package à partir d'un autre package, tu peux m'expliquer ?
Tel que tu le dis, je vois une solution qui marche :
package Foo;
BEGIN { push @Bar::ISA, "Foo"; }
Mais beurk, d'accord.
Mais pour ce que tu dis, il faut voir qu'il n'y a pas de lien obligatoire entre le nom du fichier et le nom du package qu'il va contenir. Pour prendre mon exemple de XML::XQL::DOM, un « use XML::XQL::DOM; » charge /usr/share/perl5/XML/XQL/DOM.pm, mais ce fichier contient, entre autres, « package XML::DOM::Node; ».
Emmanuel Florac wrote in message
<pan.2006.02.17.20.55.30.539801@imaginet.fr>:
Oui, je vois. Note que je ne vois pas comment on fait pour autant pour
intégrer des trucs dans le namespace d'un package à partir d'un autre
package, tu peux m'expliquer ?
Tel que tu le dis, je vois une solution qui marche :
package Foo;
BEGIN {
push @Bar::ISA, "Foo";
}
Mais beurk, d'accord.
Mais pour ce que tu dis, il faut voir qu'il n'y a pas de lien obligatoire
entre le nom du fichier et le nom du package qu'il va contenir. Pour prendre
mon exemple de XML::XQL::DOM, un « use XML::XQL::DOM; » charge
/usr/share/perl5/XML/XQL/DOM.pm, mais ce fichier contient, entre autres,
« package XML::DOM::Node; ».
Oui, je vois. Note que je ne vois pas comment on fait pour autant pour intégrer des trucs dans le namespace d'un package à partir d'un autre package, tu peux m'expliquer ?
Tel que tu le dis, je vois une solution qui marche :
package Foo;
BEGIN { push @Bar::ISA, "Foo"; }
Mais beurk, d'accord.
Mais pour ce que tu dis, il faut voir qu'il n'y a pas de lien obligatoire entre le nom du fichier et le nom du package qu'il va contenir. Pour prendre mon exemple de XML::XQL::DOM, un « use XML::XQL::DOM; » charge /usr/share/perl5/XML/XQL/DOM.pm, mais ce fichier contient, entre autres, « package XML::DOM::Node; ».
Emmanuel Florac
Le Sat, 18 Feb 2006 00:38:52 +0000, Nicolas George a écrit :
Mais pour ce que tu dis, il faut voir qu'il n'y a pas de lien obligatoire entre le nom du fichier et le nom du package qu'il va contenir. Pour prendre mon exemple de XML::XQL::DOM, un « use XML::XQL::DOM; » charge /usr/share/perl5/XML/XQL/DOM.pm, mais ce fichier contient, entre autres, « package XML::DOM::Node; ».
Mmmh et ça marche, ça ?
-- L'église est une secte qui a réussi. Ernest Renan.
Le Sat, 18 Feb 2006 00:38:52 +0000, Nicolas George a écrit :
Mais pour ce que tu dis, il faut voir qu'il n'y a pas de lien obligatoire
entre le nom du fichier et le nom du package qu'il va contenir. Pour prendre
mon exemple de XML::XQL::DOM, un « use XML::XQL::DOM; » charge
/usr/share/perl5/XML/XQL/DOM.pm, mais ce fichier contient, entre autres,
« package XML::DOM::Node; ».
Mmmh et ça marche, ça ?
--
L'église est une secte qui a réussi.
Ernest Renan.
Le Sat, 18 Feb 2006 00:38:52 +0000, Nicolas George a écrit :
Mais pour ce que tu dis, il faut voir qu'il n'y a pas de lien obligatoire entre le nom du fichier et le nom du package qu'il va contenir. Pour prendre mon exemple de XML::XQL::DOM, un « use XML::XQL::DOM; » charge /usr/share/perl5/XML/XQL/DOM.pm, mais ce fichier contient, entre autres, « package XML::DOM::Node; ».
Mmmh et ça marche, ça ?
-- L'église est une secte qui a réussi. Ernest Renan.
