mageekblog - Mot-clé - Lukas Kahwe SmithLe blog personnel de Frédéric Hardy. Au menu, PHP, agilité, FreeBSD, cuisine et photographies.2021-12-02T08:20:54+01:00Frédéric Hardyurn:md5:26874ca5b8cd4cac8d08b0e68e64f63aDotclearinterfaces == interopérabilité ?urn:md5:01c8071c940866ff885e34ef779646fe2011-10-25T12:30:00+02:002011-10-26T16:59:19+02:00mageekguyPHPinteropérabilitéLukas Kahwe SmithPHPPSR-0<p>Depuis maintenant pas mal de temps, <a href="http://blog.mageekbox.net/?post/2010/05/06/Un-coup-dur-pour-PHP">Lukas Kahwe Smith</a> milite, notamment via <a href="http://twitter.com/#!/lsmith">twitter</a>, pour que <a href="http://www.php.net">PHP</a> dispose d'un ensemble d'interfaces concernant les besoins de base que l'on retrouve dans la majorité des projets utilisant le langage afin de faciliter l'<a href="http://fr.wikipedia.org/wiki/Interopérabilité">interopérabilité</a>.</p>
<p>Il y a quelques jours, il est passé à la vitesse supérieure en publiant sur son <a href="http://blog.mageekbox.net/?post/2011/10/25/<a href=" http:="" pooteeweet.org"="">blog</a> un <a href="http://pooteeweet.org/blog/2008">billet</a> sur le sujet qui a suscité un certain nombre de <a href="http://www.hermanradtke.com/blog/please-do-not-interface-the-php-world/">réactions</a> au sein de la communauté des développeurs PHP.</p>
<p>Il y explique que le fait de disposer de telles interfaces permettrait d'intégrer plus facilement au sein du project X les composants qui lui manque en les <q>empruntant</q> au projet Y.</p> <p>Les interfaces, connues, normalisées et documentées, joueraient alors le rôle de passerelle entre les différents composants et le développeur, ce qui faciliterait leur intégration en un ensemble cohérent.</p>
<p>Il deviendrait alors possible pour le dévelopeur d'utiliser au sein d'un projet les composants externes de son choix, en fonction de ses besoins ou ses préférences.</p>
<p>Pour parler concrétememnt, s'il existait par exemple une telle interface pour les <a href="http://fr.wikipedia.org/wiki/Mapping_objet-relationnel"><abbr title="Object Relational Mapping">ORM</abbr></a> tel que <a href="http://www.propelorm.org/">Propel</a> ou <a href="http://www.doctrine-project.org/">Doctrine</a>, passer de l'un à l'autre au sein d'un projet utilisant <a href="http://symfony.com/">Symfony 2</a> deviendrait trivial, et à la rigueur, le développeur n'aurait même pas besoin de connaître la technologie sous-jacente utilisée.</p>
<p>En poussant le concept encore plus loin et si l'ensemble des interfaces nécessaires existaient, il deviendrait tout à fait possible de créer un méta-framework qui emprunterait ses composants à d'autres frameworks.</p>
<p>Si un tel mécanisme venait à voir le jour, les temps de développement seraient alors drastiquement réduits, car les développeurs n'auraient plus à réinventer la roue à chaque fois pour l'adapter à leur contexte.</p>
<p>De plus, Le déploiement d'une nouvelle solution serait également accéléré de manière significative, puisqu'elle pourrait être intégré au sein d'un projet sans nécessiter la moindre modification de code.</p>
<p>L'idée est donc très intéressante et séduisante, du moins sur le papier, car dans les faits, il est déjà démontré qu'il est difficilement applicable.</p>
<p>Tout développeur familier avec la programmation orientée objet aura en effet reconnu dans ce qui précède l'un des principes fondateurs de cette dernière.</p>
<p>En théorie, tout objet est en effet censé pouvoir être interchangeable avec un objet similaire présentant la même interface, et c'est d'ailleur la raison pour laquelle le concept de Lukas peut fonctionner.</p>
<p>Cependant, dans les faits, c'est assez rarement le cas, ou du moins ce n'est possible, dans le meilleurs des cas, que dans le cadre d'un projet maîtrisé et <q>fait maison</q> de bout en bout.</p>
<p>Les développeurs ont en effet une furieuse tendance à être insatisfait des outils qu'ils ont à leur disposition, moi le premier.</p>
<p>Et lorsqu'un développeur n'est pas content de ses outils, il crée les siens, souvent encouragé par le fait que la communauté du logiciel libre encourage cette démarche.</p>
<p>Pour s'en convaincre, il suffit de demander à un créateur de framework la raison pour laquelle il a décidé de faire son propre framework, plutôt que d'utiliser l'un de ceux existant.</p>
<p>Je suis prêt à parier que dans 80% des cas l'une des raisons données sera un sentiment d'insatisfaction par rapport aux solutions déjà existantes à l'époque.</p>
<p>L'existant pouvait être au choix et de manière non exhaustive pas totalement adapté au besoin, trop complexe à utiliser, mal ou plus maintenu, mal codé, pas assez efficace, peu performants, ou bient alors tout simplement buggé, le tout évidemment malgré un fort potentiel, j'en passe et des meilleurs.</p>
<p>Bref, au final, le développeur a toujours d'excellentes raisons pour réinventer la roue, et je vois mal pourquoi les mêmes causes ne produiraient pas les mêmes effets.</p>
<p>Alors certes, au niveau des frameworks PHP, la situation semble s'être stabilisé et il semble que deux ou trois solutions se soient aujourd'hui imposées sur le marché.</p>
<p>Cependant, rien ne dit que demain un <a href="http://hoa-project.net/">outsider</a> qui reposera sur une autre philosophie ou aura su tout simplement faire le buzz ne viendra pas bouleverser l'ordre établi et ne sera pas totalement incompatible avec l'existant.</p>
<p>De toute façon, la compatibilité et l'interopérabilité sont loin d'être un objectif majeur dans le monde de l'informatique.</p>
<p>La guerre que se sont livré et se livre encore aujourd'hui les éditeurs de systèmes d'exploitation à grand renfort d'écosystèmes fermés qui verouillent plus ou moins fortement l'utllisateur en est l'exemple le plus criant.</p>
<p>Je sais que certain vont me dire qu'à contrario, au pays du web, la situation s'améliore, et je ne peux qu'être parfaitement d'accord au vue de la progression des standards à ce niveau.</p>
<p>Cependant, pour en arriver là, il a fallu du temps, et il y a encore beaucoup d'obstacles à surmonter, et la bataille récente au sujet des <a href="http://www.framablog.org/index.php/post/2011/01/20/video-web-google-chrome-webm-h264">codec vidéo</a> ou l'annonce récente de <a href="http://www.dartlang.org/">Dart</a> n'en sont que des exemples.</p>
<p>Le fait que la <a href="http://fr.wikipedia.org/wiki/Neutralité_du_réseau">neutralité du Net</a>, pourtant à la base du succès d'Internet car c'est ce qui permet l'interopérabilité de ses services, soit actuellement menacée est également un fait qui n'encourage pas à croire que la belle théorie de la compatiblité totale soit capable de résister à la dure réalité, notamment économique.</p>
<p>Et je ne parle même pas des problèmes de licences que ce mécanisme va poser et qui feront le régal des juristes et autres coupeurs de cheveux en douze dans le sens de la longueur.</p>
<p>Dans tous les cas, le succès de l'idée de Lukas dépendra fortement de la qualité des interfaces qui seront utilisées, qui devront être à la fois simple et pratique à utiliser pour les développeurs, car dans le cas contraire, elles ne seront jamais utilisées.</p>
<p>Leur définition demandera donc énormément de concertations et de réflexion, et il y a de fortes chances que l'un de leur principal concepteur soit le <a href="http://groups.google.com/group/php-standards">PHP Standards Working Group</a>.</p>
<p>Il regroupe en effet, je <a href="http://blog.runpac.com/post/php-standards-working-group-splclassloader">cite</a>, le gratin des <q>lead developers</q> des "grands" frameworks que sont Zend Framework, Symfony, PEAR, Solar, j'en passe et des meilleurs.</p>
<p>Il est à l'origine de la proposition dite <a href="https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md">PSR-0</a> qui définie un formalisme concernant le nommage des classes permettant la mise en œuvre d'une solution d'auto-chargement de classe censé être <q>portable</q>.</p>
<p>La <a href="https://wiki.php.net/rfc/splclassloader"><abbr title="Request For Comments">RFC</abbr></a> correspondante vient d'ailleurs d'être mise à jour ainsi que le patch correspondant, suite à la démarche de Lukas qui a au moins le mérite d'avoir fait ressortir ce vieux serpent de mer sur <a href="http://news.php.net/php.internals/55921">internals@</a>.</p>
<p>Et si tout se passe bien, peut être que la version RC 1 de PHP 5.4 contiendra une SPL permettant d'utiliser le formalisme de la proposition <a href="https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md">PSR-0</a> directement au niveau du moteur de <a href="http://www.php.net">PHP</a>.</p>
<p>Cependant, ceux qui ont suivi le <a href="http://blog.runpac.com/post/php-standards-working-group-splclassloader">lien</a> de la citation précédente auront compris que cette proposition ne fait déjà pas l'unanimité parmi ses membres et il s'agit de plus d'un cercle relativement fermé, un comble pour une entité censé promouvoir l'ouverture...</p>
<p>Il faudra de plus obtenir un conscensus sur le sujet auprès des développeurs de <a href="http://www.php.net">PHP</a>, et je sais par expérience que c'est loin d'être la chose la plus facile au monde à obtenir et que c'est un travail de très longue haleine qui demande de la patience et énormément de diplomatie.</p>
<p>Et ce sera d'autant plus délicat que certains développeurs du langage sont également des développeurs de projets PHP ou ont des intérêts dans des sociétés développant de tels projets, ce qui est potentiellement une source de conflits d'intérêts.</p>
<p>Enfin, <a href="http://fabien.potencier.org/article/49/what-is-symfony2">certain</a> se positionne déjà comme pouvant fournir ces interfaces, mais sous la forme de classes, ce qui complique encore le problème, puisque dans ce cas, l'interface et son implémentation sera imposée, ce qui va je pense à l'encontre de l'idée de Lukas.</p>
<p>J'avoue donc avoir du mal à croire à l'avenir de cette belle idée, au moins à court terme, même si j'adorerais la voir se concrétiser et que je soutiens Lukas dans sa démarche.</p>
<p>Cependant, je suis également très curieux de connaître votre avis sur ce que j'appellerais dorénavant <q>l'idée de Lukas</q> !</p>http://blog.mageekbox.net/?post/2011/10/25/interfaces-interop%C3%A9rabilit%C3%A9#comment-formhttp://blog.mageekbox.net/?feed/atom/comments/299Mort de PHP6 + 90 joursurn:md5:9366f6505eb1580f0b0fd8cb5151afb32010-06-11T08:00:00+02:002010-06-11T08:59:46+02:00mageekguyPHP XbugsGearmanLukas Kahwe SmithPDOPHPPHP XPHP-FPMPHP6Pierre JoyeRasmus Lerdorfsessionthreadingtraits<p>Le <a href="http://svn.php.net/viewvc/php/php-src/trunk/">trunk</a> de <a href="http://www.php.net">PHP</a> a subit peu de changements sur la période qui vient de s'écouler.</p>
<p>En effet, un peu plus d'une quarantaine de modifications ont été faites, ce qui représente la moitié de celles qui ont été réalisées sur <a href="http://blog.mageekbox.net/?post/2010/06/03/Mort-de-PHP6-80-jours">la période précédente</a>.</p>
<p>Cependant, moindre quantité ne veut aucunement dire moindre qualité.</p> <p>Afin de ménager le suspense, je vais commencer, une fois n'est pas coutume, par le moins intéressant, à savoir les corrections de bugs, qui représente un peu moins de 25% des modifications.</p>
<p>Ainsi, les bugs <a href="http://bugs.php.net?id=51991">#51991</a>, <a href="http://bugs.php.net?id=51276">#51276</a>, <a href="http://bugs.php.net?id=50101">#50101</a>, <a href="http://bugs.php.net?id=51168">#51168</a>, <a href="http://bugs.php.net?id=51273">#51273</a>, <a href="http://bugs.php.net/?id=52001">#52001</a>, <a href="http://bugs.php.net/?id=51822">#51822</a> et <a href="http://bugs.php.net?id=52010">#52010</a> ont été corrigés, le plus important étant à mon sens le <a href="http://bugs.php.net/?id=51991">#51991</a> qui concerne <a href="http://fr.php.net/spl_autoload"><code>spl_autoload()</code></a>.</p>
<p>Un test, que <a href="http://www.php.net">PHP</a> ne passe pas pour le moment, a par ailleurs été ajouté dans le but de corriger le bug <a href="http://bugs.php.net/?id=39863">#39863</a>, qui concerne <a href="http://fr2.php.net/file_exists">file_exists()</a>.</p>
<p>Dans la continuité des corrections de bugs, le code a comme d'habitude été nettoyé par de petites corrections et optimisations qui permettront de compiler le langage plus facilement ou de supprimer des erreurs lors de la compilation.</p>
<p>Dans un tout autre registre, <a href="http://blog.thepimp.net/">Pierre Joye</a> a amélioré la fiabilité du générateur de nombre aléatoire du langage sous windows, afin de sécuriser un peu plus les sessions.</p>
<p>Du coup, la version du <a href="http://svn.php.net/viewvc/php/php-src/trunk/">trunk</a> de <a href="http://www.php.net">PHP</a> pour windows dispose maintenant également des directives <code><a href="http://fr2.php.net/manual/fr/session.configuration.php#ini.session.entropy-file">session.entropy*</a></code>.</p>
<p>L'implémentation des <a href="http://blog.mageekbox.net/?post/2010/05/17/Et-si-on-tirait-des-traits">traits</a> poursuit quant à elle son cours, avec la prise en compte des variables statiques de classe.</p>
<p>Cependant, tout cela n'est que du petit lait par rapport à l'implémentation du déférencement des tableaux (sic) lorsqu'ils sont en valeur de retour d'une fonction ou d'une méthode.</p>
<p>En effet, sous ce terme barbare, issue de ma traduction très personnelle de la <a href="http://wiki.php.net/rfc/functionarraydereferencing"><abbr title="Request For Comment">RFC</abbr> correspondante</a>, se cache une amélioration syntaxique très demandée depuis très longtemps, à savoir la possibilité d'accèder à l'index d'un tableau directement lorsque ce dernier est le résultat d'une fonction ou d'une méthode.</p>
<p>En clair, il est maintenant possible de faire avec la version du <a href="http://svn.php.net/viewvc/php/php-src/trunk/">trunk</a> cela :</p>
<blockquote><pre><code><?php<br /> <br />function fruit ()<br />{<br /> return array('a' => 'apple', 'b' => 'banana');<br />}<br /> <br />echo fruit()['a']; // apple<br /> <br />?><br /></code></pre></blockquote>
<p>Cerise sur le gâteau, le chaînage est supporté, de la manière suivante :</p>
<blockquote><pre><code><?php<br /> <br />class foo {<br /> public $array = array();<br /> <br /> public function __construct() {<br /> $this->array = array(1, 2.3);<br /> }<br /> <br /> public function bar() {<br /> return $this->array;<br /> }<br />}<br /> <br />$foo = new foo;<br />var_dump($foo->bar()[1]); // float(2.3)<br />$foo->array[] = $foo;<br />var_dump($foo->bar()[2]->bar()[2]->array[0]); // int(1)<br /> <br />?><br /></code></pre></blockquote>
<p>Les choses pourraient de plus ne pas s'arrêter là, puisqu'il y a actuellement une discussion pour supporter cela :</p>
<blockquote><pre><code><?php<br /><br />$result = new (ResultMaker()->getIt());<br />// or<br />$result = (new ResultMaker())->getIt();<br /><br />?><br /></code></pre></blockquote>
<p>Cependant, comme le montre l'exemple ci-dessus, il y a débat par rapport à la précédence de <code>new</code> par rapport aux parenthèses, et en conséquence, tant que cette ambiguïté n'est pas réglée, il y a peu de chances de voir une implémentation arriver dans le <a href="http://svn.php.net/viewvc/php/php-src/trunk/">trunk</a>.
</p>
<p>Malgré cela, cet ajout a été unanimement salué sur <a href="http://news.php.net/php.internals/">internals@</a>, qui est par ailleurs toujours engluée dans le débat concernant le contrôle du type des arguments, malgré <a href="http://news.php.net/php.internals/48700">plusieurs demandes de vote</a> de la part de <a href="http://pooteeweet.org/">Lukas Kahwe Smith</a> afin que la question soit réglée une bonne fois pour toute.</p>
<p><a href="http://pooteeweet.org/">Lukas Kahwe Smith</a> suit en effet de très prés le débat, malgré l'annonce <a href="http://blog.mageekbox.net/?post/2010/05/06/Un-coup-dur-pour-PHP">de son départ</a> de la communauté des contributeurs.</p>
<p>Il est difficile de dire si c'est parce qu'il est l'auteur <a href="http://wiki.php.net/rfc/typecheckingstrictandweak">de l'une des <abbr title="Request For Comment">RFC</abbr> sur le sujet</a>, ou s'il ne s'agissait que d'un faux départ, mais dans tous les cas, il est fidèle à sa réputation de <q>process guy</q> et tente de structurer le débat.</p>
<p>En parlant de débat, celui concernant l'intégration dans les pilotes de <a href="http://fr2.php.net/pdo">PDO</a> de fonctionnalités spécifiques au <abbr title="Système de Gestion de Base de Données">SGBD</abbr> sous-jacent est apparament terminé, puisque des fonctions spécifique à <a href="http://www.postgresql.org/">postgresql</a> ont été ajoutées dans le pilote <a href="http://fr2.php.net/pdo">PDO</a> correspondant.</p>
<p>J'ai par ailleurs eu <a href="http://news.php.net/php.internals/48697">la satisfaction d'apprendre</a> toujours via <a href="http://news.php.net/php.internals/">internals@</a> qu'il serait techniquement possible de modifier le moteur de <a href="http://www.php.net">PHP</a> afin de pouvoir définir la valeur d'une constant à l'aide d'une expression, de la manière suivante :</p>
<blockquote><pre><code><?php<br /><br />namespace foo\bar\directories {<br /> const tmp = __DIR__ . '/tmp';<br />}<br /><br />?><br /></code></pre></blockquote>
<p>Je sais donc maintenant que si j'arrive à en trouver le temps, cela vaudra le coup que je me replonge en profondeur dans le code du <a href="http://fr.wikipedia.org/wiki/Zend_Engine">Zend Engine</a>.</p>
<p>Enfin, <del>Dieu</del> <a href="http://fr.wikipedia.org/wiki/Rasmus_Lerdorf">Rasmus Lerdorf</a> a dernièrement proposé de modifier <a href="http://wiki.php.net/rfc/fpm">PHP-FPM</a> afin de pouvoir l'interfacer facilement avec <a href="http://gearman.org/">Gearman</a>.</p>
<p><a href="http://www.php.net">PHP</a> n'étant pas parallélisable, puisqu'il ne gère pas les <a href="http://fr.wikipedia.org/wiki/Thread_%28informatique%29">threads</a>, la solution passerait par l'affectation d'un processus FPM à un script <a href="http://www.php.net">PHP</a> spécifique correspondant à une tâche dévolue à <a href="http://gearman.org/">Gearman</a>.</p>
<p>J'avoue que l'idée est intelligente, mais je pense qu'il est dommage de limiter une telle fonctionnalité à <a href="http://wiki.php.net/rfc/fpm">PHP-FPM</a>.</p>
<p>J'ai bien <a href="http://news.php.net/php.internals/48726">évoqué</a> le <a href="http://fr.wikipedia.org/wiki/Thread_%28informatique%29">threading</a> comme alternative plus généraliste, mais comme d'habitude, <del>la colère divine a frappé</del> <a href="http://fr.wikipedia.org/wiki/Rasmus_Lerdorf">Ramus</a> a <a href="http://news.php.net/php.internals/48727">refusé net</a> l'idée.</p>
<p>Cette rétrospective est maintenant terminée, vous pouvez reprendre une activité normale.</p>http://blog.mageekbox.net/?post/2010/06/11/Mort-de-PHP6-90-jours#comment-formhttp://blog.mageekbox.net/?feed/atom/comments/140