Tiens ben du coup chaque objet suscetible d'avoir une valeur envoyée a un flux va implementer une methode qui écrit sur un flux, et ce pour chaque variable (put ceci, put cela). Alors qu'on aura quand meme *tres probablement* des getters ... quelle bonne idée
Voilà, post un peu confus désolé c'est les vacances. Pour essayer de donner le bon angle de lecture à mon post je tiens à rappeller que j'aime bien PHP, d'autant plus que je l'ai dénigré les dernières années. Mais maintenant je sais ce qu'il vaut, je sais m'en servir (edit: plus ou moins ) donc c'est un langage qui m'est utile et qui me plait. Ce post n'est pas là pour descendre php, bien que je puisse parler de ses faiblesses :
Functional programming oui. C'est un paradigme simple, et les langages FP renforcent ce paradigme. En objet chaque développeur va avoir sa définition de l'OOP ...
En PHP tu n'as pas d'envoi de message. Tu peux appeler une méthode et dire à tes élèves "là, j'envoie un message" mais c'est des conneries. Tu appelles simplement une fonction avec certains paramètres dont un paramètre caché,
En PHP tu n'as pas de vraie isolation au sein d'une classe. Tu peux toujours taper sur des globales, tu dois déclarer des public/protected/private ou alors des getters idiots* qui renvoient bêtement une variable protected (*idiots mais nécessaires puisqu'on les définit comme envoi de message). De plus la portée est définie par la classe, ce qui donne la possibilité de faire ça :
Je ne dis pas que c'est mal, j'ai du m'en servir aussi au moins une fois. Mais simplement je trouve qu'on est loin du paradigme objet originel. Et que chaque langage faisant les choses à sa sauce, on a surtout un paradigme de plus en plus flou.
Du coup ce que je fais moi : J'analyse mon problème en essayant de définir les différents types de données qui interagissent entre eux, j'appelle ça des classes et dedans je regroupe les fonctions qui pourraient connaitre la représentation interne du type en FP, ce qui correspond en gros aux fonctions pouvant manipuler
Et au final tout le monde est content. Après avoir bien regardé le code de Laravel je me rends compte que en fait tout le monde fait comme ça (enfin du moins la lecture du code permet de mettre en évidence ce type d'organisation, rien de nouveau au final). Mais je trouve, comme dans l'article d'oxman, qu'on ferait mieux de s'en tenir aux types de données et à leurs interfaces, au coeur du problème, au lieu de multiplier les classes. Est-ce que chaque classe doit vraiment implémenter des putters en plus de getters maintenant ?
Petite propagande perso : les seuls moments ou j'ai l'impression de faire de l'objet de façon naturelles (i.e. sans me demander toutes les trois secondes si je donne telle responsabilité à la bonne classe) c'est avec Erlang, où je bénéficie de l'envoie de message pour les appels de méthodes et pour les
Voilà, post un peu confus désolé c'est les vacances. Pour essayer de donner le bon angle de lecture à mon post je tiens à rappeller que j'aime bien PHP, d'autant plus que je l'ai dénigré les dernières années. Mais maintenant je sais ce qu'il vaut, je sais m'en servir (edit: plus ou moins ) donc c'est un langage qui m'est utile et qui me plait. Ce post n'est pas là pour descendre php, bien que je puisse parler de ses faiblesses :
(10-08-2014, 01:13 PM)Sephi-Chan a écrit :(10-08-2014, 01:12 PM)niahoo a écrit : (Suite de mon post) Je vais dire un truc un peu pédant mais depuis que je fais du FP et de l'objet en erlang, ma façon de coder objet en php s'est nettement éloignée de ce genre de considerations sur la syntaxe ou la façon d'ecrire.
C'est à dire ?
FP pour functional programming je suppose ?
Functional programming oui. C'est un paradigme simple, et les langages FP renforcent ce paradigme. En objet chaque développeur va avoir sa définition de l'OOP ...
En PHP tu n'as pas d'envoi de message. Tu peux appeler une méthode et dire à tes élèves "là, j'envoie un message" mais c'est des conneries. Tu appelles simplement une fonction avec certains paramètres dont un paramètre caché,
$this
. D'ailleurs, si tu regardes comment on implémente une classe en Lua (edit: sans les metatables, avec self, ce qui d'ailleurs n'est pas la manière la plus performante ni la plus fun) tu vois exactement ce mécanisme.En PHP tu n'as pas de vraie isolation au sein d'une classe. Tu peux toujours taper sur des globales, tu dois déclarer des public/protected/private ou alors des getters idiots* qui renvoient bêtement une variable protected (*idiots mais nécessaires puisqu'on les définit comme envoi de message). De plus la portée est définie par la classe, ce qui donne la possibilité de faire ça :
<?php
class A {
private $v;
public function __construct($v) {
$this->v = $v;
}
public function foo (A $a) {
echo $a->v , "\n";
}
}
class B extends A {
}
$a1 = new A(1);
$a2 = new A(2);
$a1->foo($a2); // 2
$b = new B(3);
$b->foo($a2); // 2
Je ne dis pas que c'est mal, j'ai du m'en servir aussi au moins une fois. Mais simplement je trouve qu'on est loin du paradigme objet originel. Et que chaque langage faisant les choses à sa sauce, on a surtout un paradigme de plus en plus flou.
Du coup ce que je fais moi : J'analyse mon problème en essayant de définir les différents types de données qui interagissent entre eux, j'appelle ça des classes et dedans je regroupe les fonctions qui pourraient connaitre la représentation interne du type en FP, ce qui correspond en gros aux fonctions pouvant manipuler
$this
en PHP. Je mets ces fonctions dans ma classe. On parle ici des fonctions public
puisque les autres c'est moi qui choisit ce que j'en fais.Et au final tout le monde est content. Après avoir bien regardé le code de Laravel je me rends compte que en fait tout le monde fait comme ça (enfin du moins la lecture du code permet de mettre en évidence ce type d'organisation, rien de nouveau au final). Mais je trouve, comme dans l'article d'oxman, qu'on ferait mieux de s'en tenir aux types de données et à leurs interfaces, au coeur du problème, au lieu de multiplier les classes. Est-ce que chaque classe doit vraiment implémenter des putters en plus de getters maintenant ?
Petite propagande perso : les seuls moments ou j'ai l'impression de faire de l'objet de façon naturelles (i.e. sans me demander toutes les trois secondes si je donne telle responsabilité à la bonne classe) c'est avec Erlang, où je bénéficie de l'envoie de message pour les appels de méthodes et pour les
return
et de l'isolation totale (dans les limites de la machine) de mes objets. (Bon et du polymorphisme mais on l'a aussi de façon très satisfaisante en PHP via l'héritage et les iterfaces).