Question existentielle a propos des gett er et setter dans une classe.
16 réponses
Mickael Wolff
Bonjour,
En développant aujourd'hui, je me suis posé une question existentielle
qui m'empêchera de dormir pendant plusieurs années : comment implémenter
proprement les accesseurs d'une classe. Je m'explique en prenant un
exemple simple (écrit en PHP5). J'ignore volontairement les tests pour
éviter d'alourdir les exemples. En fait, j'hésite toujours entre les
trois philosophies suivantes, sans pouvoir trancher réellement.
La première approche me semble être la plus proche de la philosophie
PHP5. On utilises que des méthodes magiques. Le problème ici est que si
on a plus d'une donnée à protéger dans sa classe, les méthodes __get et
__set deviennent rapidement illisibles. Et surtout, lors d'un héritage
on a des problèmes assurés avec le polymorphisme.
class directAccess
{
public function __construct($value)
{
$this->attribute = $value ;
}
public function __get($aname)
{
// Travail de vérification
return clone $this->$aname ;
}
public function __set($aname, $avalue)
{
// Travail de vériication
$this->$aname = $avalue ;
}
protected $attribute ;
}
La seconde approche serait plus proche du C++, mais avec la surcharge
des méthodes en moins. Le seul inconvénient qu'on peut y trouver, c'est
l'imposibilité d'assigner la valeur null sans devoir recourir à une
méthode supplémentaire.
class allInOne
{
public function __construct($value)
{
$this->attribute = $value ;
}
public function attribute($avalue=null)
{
if(is_null($avalue))
{
// Travail de vérification
return clone $this->attribute ;
}
else
{
// Travail de vériication
$this->attribute = $avalue ;
}
}
public function del($aname)
{
$this->$name = null ;
}
protected $attribute ;
}
La troisième méthode est certainement la plus propre d'un point de vue
de la conception. Le désavantage est la lourdeur d'écriture.
class javaStyle
{
public function __construct($value)
{
$this->attribute = $value ;
}
public function getAttribute()
{
// Travail de vérification
return clone $this->attribute ;
}
public function setAttribute($avalue)
{
// Travail de vériication
$this->attribute = $avalue ;
}
protected $attribute ;
}
Laquelle de ces méthodes utilisez-vous ? Peut-être un mélange ? Ou
encore en fonction de la situation rencontrée ? J'ai conscience que
c'est un concentré de troll, car personne n'est d'accord sur la façon de
développer. Mais ça m'intéresse d'avoir vos avis.
Visiblement, la guerre entre ceux qui veulent contrôler, et ceux qui font confiance à ce qui est renseigné par l'utilisateur de la classe fait rage :)
Voila. Comme il y a 6 mois, mais pire. On ne va pas tout le temps réécrire les meme choses....
Et comme d'habitude, on oppose sécurité et performances. C'est bien dommage je trouve.
Oui, cela dépend des besoins et du contexte. Difficile de tirer des règles générales dans ce domaine.
Surtout que seul Apple fait des vrais ordinateurs, pas de salut hors de Lynx, le C c'est pour les taffioles, l'Objet ca sert à rien et Windows c'est de la merde. D'autres questions ?
Comment fais-tu les attributs calculés en PHP ? Avec __get/__set ?
Je mets des setter manuellement moi meme quand j'en ai besoin, c'est à dire que je les rajoute au fur et a msure sur le gros projet que j'ai repris l'an dernier quand j'ai le temps. Il y a tellement de merdouilles un peu partout que par exemple, jouer sur les vérifications des formats des dates dans les setter a été le moyen le moins crade que j'ai pus trouver, et ce encore une fois, dans les circonstances que j'ai pu rencontrer.
Merci en tout cas de vos avis, ça fait plaisir de savoir que le conflit qui me perturbe est universel.
Comme beaucoup d'autres :)
Ceci dit la solution est je pense dans la réponse d'Olivier : une bonne macro dans l'éditeur :)
@++
Stef
Visiblement, la guerre entre ceux qui veulent contrôler, et ceux qui
font confiance à ce qui est renseigné par l'utilisateur de la classe
fait rage :)
Voila. Comme il y a 6 mois, mais pire. On ne va pas tout le temps réécrire
les meme choses....
Et comme d'habitude, on oppose sécurité et performances.
C'est bien dommage je trouve.
Oui, cela dépend des besoins et du contexte. Difficile de tirer des règles
générales dans ce domaine.
Surtout que seul Apple fait des vrais ordinateurs, pas de salut hors de
Lynx, le C c'est pour les taffioles, l'Objet ca sert à rien et Windows c'est
de la merde. D'autres questions ?
Comment fais-tu les attributs calculés en PHP ? Avec __get/__set ?
Je mets des setter manuellement moi meme quand j'en ai besoin, c'est à dire
que je les rajoute au fur et a msure sur le gros projet que j'ai repris l'an
dernier quand j'ai le temps. Il y a tellement de merdouilles un peu partout
que par exemple, jouer sur les vérifications des formats des dates dans les
setter a été le moyen le moins crade que j'ai pus trouver, et ce encore une
fois, dans les circonstances que j'ai pu rencontrer.
Merci en tout cas de vos avis, ça fait plaisir de savoir que le
conflit qui me perturbe est universel.
Comme beaucoup d'autres :)
Ceci dit la solution est je pense dans la réponse d'Olivier : une bonne
macro dans l'éditeur :)
Visiblement, la guerre entre ceux qui veulent contrôler, et ceux qui font confiance à ce qui est renseigné par l'utilisateur de la classe fait rage :)
Voila. Comme il y a 6 mois, mais pire. On ne va pas tout le temps réécrire les meme choses....
Et comme d'habitude, on oppose sécurité et performances. C'est bien dommage je trouve.
Oui, cela dépend des besoins et du contexte. Difficile de tirer des règles générales dans ce domaine.
Surtout que seul Apple fait des vrais ordinateurs, pas de salut hors de Lynx, le C c'est pour les taffioles, l'Objet ca sert à rien et Windows c'est de la merde. D'autres questions ?
Comment fais-tu les attributs calculés en PHP ? Avec __get/__set ?
Je mets des setter manuellement moi meme quand j'en ai besoin, c'est à dire que je les rajoute au fur et a msure sur le gros projet que j'ai repris l'an dernier quand j'ai le temps. Il y a tellement de merdouilles un peu partout que par exemple, jouer sur les vérifications des formats des dates dans les setter a été le moyen le moins crade que j'ai pus trouver, et ce encore une fois, dans les circonstances que j'ai pu rencontrer.
Merci en tout cas de vos avis, ça fait plaisir de savoir que le conflit qui me perturbe est universel.
Comme beaucoup d'autres :)
Ceci dit la solution est je pense dans la réponse d'Olivier : une bonne macro dans l'éditeur :)
@++
Stef
P'tit Marcel
<pub-éhontée> Accessoirement, si tu aimes vraiment l'OO, tu devrais regarder du côté de Python ou de Ruby... </pub-éhontée>
Traître ! Qu'on le traîne au pilori :-))
-- P'tit Marcel stats sur les forums modérés http://www.centrale-lyon.org/ng/
<pub-éhontée>
Accessoirement, si tu aimes vraiment l'OO, tu devrais regarder du côté
de Python ou de Ruby...
</pub-éhontée>
Traître ! Qu'on le traîne au pilori :-))
--
P'tit Marcel
stats sur les forums modérés http://www.centrale-lyon.org/ng/
<pub-éhontée> Accessoirement, si tu aimes vraiment l'OO, tu devrais regarder du côté de Python ou de Ruby... </pub-éhontée>
Traître ! Qu'on le traîne au pilori :-))
-- P'tit Marcel stats sur les forums modérés http://www.centrale-lyon.org/ng/
Bruno Desthuilliers
Je vois qu'il y a là beaucoup de certitudes, voir limite une certaine intolérance : )
???
Je rappelle que j'ai seulement dit que le fait de s'appuyer sur les usages de certains n'était pas suffisant pour décréter que les usages d'autres étaient inconvenants.
Je ne me souviens pas avoir utilisé un terme comme "inconvenant".
J'ai aussi rajouté qu'il y avait les deux écoles et que je me gardais bien de trancher de manière définitive meme si j'avais ma préférence.
Par contre, je n'estime pas nécessaire d'arriver au stade des noms d'oiseaux
Là encore, je ne vois pas à quoi tu fais référence. Où donc ai-je employer des "noms d'oiseau" ??? Je crains qu'on ne soit en pleine incompréhension, là.
(snip)
Tentons tout de meme de récapituler quelque peut :
[1] C'est à dire par expérience effective de plusieurs années sur du code en production. Et si mon expérience personnelle te sembles insuffisante, il y a l'expérience collective accumulée par les développeurs Python depuis plus de quinze ans, sur des projets de toutes tailles et Arguments non recevables.
Argument on ne peut plus recevable, au contraire.
Non.
Arguments non recevables.
Donc, tu considères que l'expérience pratique n'est pas un argument recevable ?
Si oui, je ne vois guère l'intérêt de poursuivre la discussion, dans la mesure où - contrairement au modèle relationnel ou à la programmation fonctionnelle - la POO ne s'appuie sur aucune base théorique solide - tout au plus quelques définitions floues, et autant d'implémentations qu'il y a de compréhension possibles de ces définitions...
Je peux aller te chercher des sommités et des développeurs au CV bien plus conséquent que le tien ou le mien, qui te dirons le contraire.
Il serait intéressant d'avoir des des statistiques sur l'implémentation des setters dans les langages qui les imposent (j'entends par là ceux qui n'ont pas de support pour les attributs calculés). AMHA, le résulat serait que le cas général, et de très loin, consiste à juste affecter la valeur à l'attribut. Je n'ai bien sûr aucun chiffre à l'appui, mais dans tout le code que j'ai vu passer, c'est bien le cas.
Par ailleurs, travaillant de façon régulière et depuis plusieurs années avec un langage ayant un support pour les attributs calculés (donc pas de nécessité de coder systématiquement des accesseurs explicites par défaut), j'ai pu constater que - hormis des cas d'usages particuliers (ORMs par exemple) - la nécessité effective d'avoir recours aux attributs calculés pour contrôle de validité était plus que marginale.
Petite précision, accessoirement, j'ai appris Java avant Python, et j'étais alors moi-même un control-freak paranoïaque de la pire espèce. Voir que du code en production s'appuyait sur un langage sans vérification de type à la compilation, sans restricteurs d'accès, et dans lequel la norme est d'employer des attributs publics m'a fait un choc. Cela contredisait tout ce qu'on m'avait appris jusque là, et donc ça ne pouvait forcément pas fonctionner. Et pourtant, comment nier l'évidence pratique effective ?
Bref, il ne s'agit pas d'"avis" ou d'"opinion", mais de faits constatables par toute personne s'en donnant la peine.
Et cela ne sera pas non plus évident qu'ils aient raison.
D'une manière générale, dans ce domaine, c'est rarement celui qui crie le plus fort qui a raison. Celui qui s'en sort le mieux est généralement celui qui comprend de quoi on parle et qui s'adapte aux environnements et aux besoins qu'il croise.
Tout à fait d'accord sur ce point au moins.
Je sais par expérience
Tiens c'est marrant, moi aussi. Ca nous fait une belle jambe, n'est ce pas ?
Sur des gros projets. En prod. Demande donc à Google ce qu'ils en pensent... Je te dirais que ça dépend des projets. Je ne suis pas très loin de leur
centre de Dublin [ils en ont un deuxième en Allemagne], et vu ce que m'ont rapporté les collègues qui y travaillent, ca dépend vachement des personnes et des technos.
Bien sûr. En Java ou en C++, il n'est évidemment pas (sérieusement) possible de faire l'économie des accesseurs, puisque dans ce cas l'interface ne serait plus découplée de l'implémentation. Je rappelle que je parles du contexte de langages supportants les attributs calculés.
Et surtout, la qualité des développements internes de Google est tout sauf une référence, surtout ces derniers temps.
C'est un avis. Mais en l'occurrence, je ne faisais pas forcément référence à des gadgets sur leur site. En tout état de cause, si tu a tes entrées chez Google, tu pourras discuter de ces points avec deux de leurs employés, Guido Van Rossum et Alex Martelli.
Tu ne me prendrais pas un peu pour un bleubite, là ?-)
Argument inutile et encore une fois non recevable.
Aurais-tu laisser ton humour au vestiaire ? Ou raté le smiley ?
Si tu codes en Java ou en C++, c'est un non-choix. En PHP, c'est à mon très humble avis - lequel se base sur plusieurs années d'expérience professionnelle - une perte de temps pure et simple (tant bien sûr que tu n'a pas *effectivement* besoin de l'accesseur).
Il se trouve que régulièrement, j'ai BESOIN des accesseurs.
Fort bien. Il convient donc - dans ce cas - de les utiliser. Ai-je dit le contraire ?
(snip choses surprenantes à propos d'attaques personnelles)
Mais tout de meme : que de certitudes.....
cf plus haut. Et désolé d'être sordidement pragmatique au point de faire plus confiance aux faits qu'aux théories.
Bon, ceci étant dit, il semble évident non seulement que nous ne sommes pas du même avis, mais également que tant mes points de vues que ma façon de m'exprimer t'insupporte - au point que tu vois des attaques personnelles dans des endroits très surprenants. J'en suis profondément désolé, mais comme je n'ai pas pour autant l'intention de changer, je te propose en toute simplicité de me mettre dans ta kill-file - ou à défaut d'ignorer mes écrits -, ce qui nous évitera à l'avenir ce genre d'échanges profondémment stériles.
Cordialement.
Je vois qu'il y a là beaucoup de certitudes, voir limite une certaine
intolérance : )
???
Je rappelle que j'ai seulement dit que le fait de s'appuyer sur les usages
de certains n'était pas suffisant pour décréter que les usages d'autres
étaient inconvenants.
Je ne me souviens pas avoir utilisé un terme comme "inconvenant".
J'ai aussi rajouté qu'il y avait les deux écoles et
que je me gardais bien de trancher de manière définitive meme si j'avais ma
préférence.
Par contre, je n'estime pas nécessaire d'arriver au stade des noms d'oiseaux
Là encore, je ne vois pas à quoi tu fais référence. Où donc ai-je
employer des "noms d'oiseau" ??? Je crains qu'on ne soit en pleine
incompréhension, là.
(snip)
Tentons tout de meme de récapituler quelque peut :
[1] C'est à dire par expérience effective de plusieurs années sur du
code en production. Et si mon expérience personnelle te sembles
insuffisante, il y a l'expérience collective accumulée par les
développeurs Python depuis plus de quinze ans, sur des projets de toutes
tailles et
Arguments non recevables.
Argument on ne peut plus recevable, au contraire.
Non.
Arguments non recevables.
Donc, tu considères que l'expérience pratique n'est pas un argument
recevable ?
Si oui, je ne vois guère l'intérêt de poursuivre la discussion, dans la
mesure où - contrairement au modèle relationnel ou à la programmation
fonctionnelle - la POO ne s'appuie sur aucune base théorique solide -
tout au plus quelques définitions floues, et autant d'implémentations
qu'il y a de compréhension possibles de ces définitions...
Je peux aller te chercher des sommités et des développeurs au CV bien plus
conséquent que le tien ou le mien, qui te dirons le contraire.
Il serait intéressant d'avoir des des statistiques sur l'implémentation
des setters dans les langages qui les imposent (j'entends par là ceux
qui n'ont pas de support pour les attributs calculés). AMHA, le résulat
serait que le cas général, et de très loin, consiste à juste affecter la
valeur à l'attribut. Je n'ai bien sûr aucun chiffre à l'appui, mais dans
tout le code que j'ai vu passer, c'est bien le cas.
Par ailleurs, travaillant de façon régulière et depuis plusieurs années
avec un langage ayant un support pour les attributs calculés (donc pas
de nécessité de coder systématiquement des accesseurs explicites par
défaut), j'ai pu constater que - hormis des cas d'usages particuliers
(ORMs par exemple) - la nécessité effective d'avoir recours aux
attributs calculés pour contrôle de validité était plus que marginale.
Petite précision, accessoirement, j'ai appris Java avant Python, et
j'étais alors moi-même un control-freak paranoïaque de la pire espèce.
Voir que du code en production s'appuyait sur un langage sans
vérification de type à la compilation, sans restricteurs d'accès, et
dans lequel la norme est d'employer des attributs publics m'a fait un
choc. Cela contredisait tout ce qu'on m'avait appris jusque là, et donc
ça ne pouvait forcément pas fonctionner. Et pourtant, comment nier
l'évidence pratique effective ?
Bref, il ne s'agit pas d'"avis" ou d'"opinion", mais de faits
constatables par toute personne s'en donnant la peine.
Et cela ne
sera pas non plus évident qu'ils aient raison.
D'une manière générale, dans ce domaine, c'est rarement celui qui crie le
plus fort qui a raison. Celui qui s'en sort le mieux est généralement celui
qui comprend de quoi on parle et qui s'adapte aux environnements et aux
besoins qu'il croise.
Tout à fait d'accord sur ce point au moins.
Je sais par expérience
Tiens c'est marrant, moi aussi. Ca nous fait une belle jambe, n'est ce pas ?
Sur des gros projets. En prod. Demande donc à Google ce qu'ils en
pensent...
Je te dirais que ça dépend des projets. Je ne suis pas très loin de leur
centre de Dublin [ils en ont un deuxième en Allemagne], et vu ce que m'ont
rapporté les collègues qui y travaillent, ca dépend vachement des personnes
et des technos.
Bien sûr. En Java ou en C++, il n'est évidemment pas (sérieusement)
possible de faire l'économie des accesseurs, puisque dans ce cas
l'interface ne serait plus découplée de l'implémentation. Je rappelle
que je parles du contexte de langages supportants les attributs calculés.
Et surtout, la qualité des développements internes de Google
est tout sauf une référence, surtout ces derniers temps.
C'est un avis. Mais en l'occurrence, je ne faisais pas forcément
référence à des gadgets sur leur site. En tout état de cause, si tu a
tes entrées chez Google, tu pourras discuter de ces points avec deux de
leurs employés, Guido Van Rossum et Alex Martelli.
Tu ne me prendrais pas un peu pour un bleubite, là ?-)
Argument inutile et encore une fois non recevable.
Aurais-tu laisser ton humour au vestiaire ? Ou raté le smiley ?
Si tu codes en Java ou en C++, c'est un non-choix. En PHP, c'est à mon
très humble avis - lequel se base sur plusieurs années d'expérience
professionnelle - une perte de temps pure et simple (tant bien sûr que tu
n'a pas *effectivement* besoin de l'accesseur).
Il se trouve que régulièrement, j'ai BESOIN des accesseurs.
Fort bien. Il convient donc - dans ce cas - de les utiliser. Ai-je dit
le contraire ?
(snip choses surprenantes à propos d'attaques personnelles)
Mais tout de meme : que de certitudes.....
cf plus haut. Et désolé d'être sordidement pragmatique au point de faire
plus confiance aux faits qu'aux théories.
Bon, ceci étant dit, il semble évident non seulement que nous ne sommes
pas du même avis, mais également que tant mes points de vues que ma
façon de m'exprimer t'insupporte - au point que tu vois des attaques
personnelles dans des endroits très surprenants. J'en suis profondément
désolé, mais comme je n'ai pas pour autant l'intention de changer, je te
propose en toute simplicité de me mettre dans ta kill-file - ou à défaut
d'ignorer mes écrits -, ce qui nous évitera à l'avenir ce genre
d'échanges profondémment stériles.
Je vois qu'il y a là beaucoup de certitudes, voir limite une certaine intolérance : )
???
Je rappelle que j'ai seulement dit que le fait de s'appuyer sur les usages de certains n'était pas suffisant pour décréter que les usages d'autres étaient inconvenants.
Je ne me souviens pas avoir utilisé un terme comme "inconvenant".
J'ai aussi rajouté qu'il y avait les deux écoles et que je me gardais bien de trancher de manière définitive meme si j'avais ma préférence.
Par contre, je n'estime pas nécessaire d'arriver au stade des noms d'oiseaux
Là encore, je ne vois pas à quoi tu fais référence. Où donc ai-je employer des "noms d'oiseau" ??? Je crains qu'on ne soit en pleine incompréhension, là.
(snip)
Tentons tout de meme de récapituler quelque peut :
[1] C'est à dire par expérience effective de plusieurs années sur du code en production. Et si mon expérience personnelle te sembles insuffisante, il y a l'expérience collective accumulée par les développeurs Python depuis plus de quinze ans, sur des projets de toutes tailles et Arguments non recevables.
Argument on ne peut plus recevable, au contraire.
Non.
Arguments non recevables.
Donc, tu considères que l'expérience pratique n'est pas un argument recevable ?
Si oui, je ne vois guère l'intérêt de poursuivre la discussion, dans la mesure où - contrairement au modèle relationnel ou à la programmation fonctionnelle - la POO ne s'appuie sur aucune base théorique solide - tout au plus quelques définitions floues, et autant d'implémentations qu'il y a de compréhension possibles de ces définitions...
Je peux aller te chercher des sommités et des développeurs au CV bien plus conséquent que le tien ou le mien, qui te dirons le contraire.
Il serait intéressant d'avoir des des statistiques sur l'implémentation des setters dans les langages qui les imposent (j'entends par là ceux qui n'ont pas de support pour les attributs calculés). AMHA, le résulat serait que le cas général, et de très loin, consiste à juste affecter la valeur à l'attribut. Je n'ai bien sûr aucun chiffre à l'appui, mais dans tout le code que j'ai vu passer, c'est bien le cas.
Par ailleurs, travaillant de façon régulière et depuis plusieurs années avec un langage ayant un support pour les attributs calculés (donc pas de nécessité de coder systématiquement des accesseurs explicites par défaut), j'ai pu constater que - hormis des cas d'usages particuliers (ORMs par exemple) - la nécessité effective d'avoir recours aux attributs calculés pour contrôle de validité était plus que marginale.
Petite précision, accessoirement, j'ai appris Java avant Python, et j'étais alors moi-même un control-freak paranoïaque de la pire espèce. Voir que du code en production s'appuyait sur un langage sans vérification de type à la compilation, sans restricteurs d'accès, et dans lequel la norme est d'employer des attributs publics m'a fait un choc. Cela contredisait tout ce qu'on m'avait appris jusque là, et donc ça ne pouvait forcément pas fonctionner. Et pourtant, comment nier l'évidence pratique effective ?
Bref, il ne s'agit pas d'"avis" ou d'"opinion", mais de faits constatables par toute personne s'en donnant la peine.
Et cela ne sera pas non plus évident qu'ils aient raison.
D'une manière générale, dans ce domaine, c'est rarement celui qui crie le plus fort qui a raison. Celui qui s'en sort le mieux est généralement celui qui comprend de quoi on parle et qui s'adapte aux environnements et aux besoins qu'il croise.
Tout à fait d'accord sur ce point au moins.
Je sais par expérience
Tiens c'est marrant, moi aussi. Ca nous fait une belle jambe, n'est ce pas ?
Sur des gros projets. En prod. Demande donc à Google ce qu'ils en pensent... Je te dirais que ça dépend des projets. Je ne suis pas très loin de leur
centre de Dublin [ils en ont un deuxième en Allemagne], et vu ce que m'ont rapporté les collègues qui y travaillent, ca dépend vachement des personnes et des technos.
Bien sûr. En Java ou en C++, il n'est évidemment pas (sérieusement) possible de faire l'économie des accesseurs, puisque dans ce cas l'interface ne serait plus découplée de l'implémentation. Je rappelle que je parles du contexte de langages supportants les attributs calculés.
Et surtout, la qualité des développements internes de Google est tout sauf une référence, surtout ces derniers temps.
C'est un avis. Mais en l'occurrence, je ne faisais pas forcément référence à des gadgets sur leur site. En tout état de cause, si tu a tes entrées chez Google, tu pourras discuter de ces points avec deux de leurs employés, Guido Van Rossum et Alex Martelli.
Tu ne me prendrais pas un peu pour un bleubite, là ?-)
Argument inutile et encore une fois non recevable.
Aurais-tu laisser ton humour au vestiaire ? Ou raté le smiley ?
Si tu codes en Java ou en C++, c'est un non-choix. En PHP, c'est à mon très humble avis - lequel se base sur plusieurs années d'expérience professionnelle - une perte de temps pure et simple (tant bien sûr que tu n'a pas *effectivement* besoin de l'accesseur).
Il se trouve que régulièrement, j'ai BESOIN des accesseurs.
Fort bien. Il convient donc - dans ce cas - de les utiliser. Ai-je dit le contraire ?
(snip choses surprenantes à propos d'attaques personnelles)
Mais tout de meme : que de certitudes.....
cf plus haut. Et désolé d'être sordidement pragmatique au point de faire plus confiance aux faits qu'aux théories.
Bon, ceci étant dit, il semble évident non seulement que nous ne sommes pas du même avis, mais également que tant mes points de vues que ma façon de m'exprimer t'insupporte - au point que tu vois des attaques personnelles dans des endroits très surprenants. J'en suis profondément désolé, mais comme je n'ai pas pour autant l'intention de changer, je te propose en toute simplicité de me mettre dans ta kill-file - ou à défaut d'ignorer mes écrits -, ce qui nous évitera à l'avenir ce genre d'échanges profondémment stériles.
Cordialement.
slambert
D'une manière générale, dans ce domaine, c'est rarement celui qui crie le plus fort qui a raison. Celui qui s'en sort le mieux est généralement celui qui comprend de quoi on parle et qui s'adapte aux environnements et aux besoins qu'il croise. Tout à fait d'accord sur ce point au moins.
Tenons en nous là.
Stef
D'une manière générale, dans ce domaine, c'est rarement celui qui crie le
plus fort qui a raison. Celui qui s'en sort le mieux est généralement
celui qui comprend de quoi on parle et qui s'adapte aux environnements et
aux besoins qu'il croise.
Tout à fait d'accord sur ce point au moins.
D'une manière générale, dans ce domaine, c'est rarement celui qui crie le plus fort qui a raison. Celui qui s'en sort le mieux est généralement celui qui comprend de quoi on parle et qui s'adapte aux environnements et aux besoins qu'il croise. Tout à fait d'accord sur ce point au moins.
Tenons en nous là.
Stef
Bruno Desthuilliers
Surtout que seul Apple fait des vrais ordinateurs, pas de salut hors de Lynx, le C c'est pour les taffioles, l'Objet ca sert à rien et Windows c'est de la merde. D'autres questions ?
Oui : Vim ou Emacs ?-)
Surtout que seul Apple fait des vrais ordinateurs, pas de salut hors de
Lynx, le C c'est pour les taffioles, l'Objet ca sert à rien et Windows c'est
de la merde. D'autres questions ?
Surtout que seul Apple fait des vrais ordinateurs, pas de salut hors de Lynx, le C c'est pour les taffioles, l'Objet ca sert à rien et Windows c'est de la merde. D'autres questions ?
Oui : Vim ou Emacs ?-)
Bruno Desthuilliers
<pub-éhontée> Accessoirement, si tu aimes vraiment l'OO, tu devrais regarder du côté de Python ou de Ruby... </pub-éhontée>
Traître ! Qu'on le traîne au pilori :-))
Avec tout le mal que j'ai déjà dit de PHP ici, je m'étonne que tu ne te réveilles que maintenant... Sur d'autres NG, je me serais fait lyncher depuis longtemps !-)
<pub-éhontée>
Accessoirement, si tu aimes vraiment l'OO, tu devrais regarder du côté
de Python ou de Ruby...
</pub-éhontée>
Traître ! Qu'on le traîne au pilori :-))
Avec tout le mal que j'ai déjà dit de PHP ici, je m'étonne que tu ne te
réveilles que maintenant... Sur d'autres NG, je me serais fait lyncher
depuis longtemps !-)
<pub-éhontée> Accessoirement, si tu aimes vraiment l'OO, tu devrais regarder du côté de Python ou de Ruby... </pub-éhontée>
Traître ! Qu'on le traîne au pilori :-))
Avec tout le mal que j'ai déjà dit de PHP ici, je m'étonne que tu ne te réveilles que maintenant... Sur d'autres NG, je me serais fait lyncher depuis longtemps !-)
