mageekblog - Mot-clé - Lukas Kahwe Smith - CommentairesLe 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é ? - MathRobinurn:md5:6506f8ec6d72089e2da970344dc2d7942011-10-25T23:58:10+02:002011-10-26T07:17:26+02:00MathRobin<p>J'ai beaucoup codé en Java et .Net où les interfaces sont omniprésentes. Typiquement le coup des itérateurs ou celui des collections. C'est bête comme bonjour, mais sérieusement le temps qu'on gagne est tellement précieux.</p>interfaces == interopérabilité ? - metagotourn:md5:2506a3d40a421344415ecc44a50afe5d2011-10-25T18:00:22+02:002011-10-25T17:31:54+02:00metagoto<p>Dans les faits, je n'ai pas l'impression que beaucoup de monde/projets utilisent l'autoloading tel que spécifié dans PSR-0, en tout cas de manière exclusive. Des solutions plus spécifiques et appropriées sont mises en oeuvre selon les besoins (prenons simplement comme exemple Symfony2 et ZF2 qui proposent plusieurs stratégies).<br />
Je pense qu'il fallait s'y attendre, et ceci pour 36 raisons. En tout cas, l'essentiel est que le mécanisme primitif d'autoloading de php fasse son job. C'était le cas avant les namespaces et c'est toujours le cas aujourd'hui.</p>
<p>L'interopérabilité de Lukas se joue au niveau de la librairie. Ca reste donc optionnel par nature et ne compromet pas php lui même. Du coup, il n'y a rien de mal à ce que des gens réfléchissent à ces problématiques d'interfaces et tous ces trucs. De toute façon, si cela ne se fait pas de manière collégiale au sein d'un Working Group, cela se fera par la force sur github <img src="/themes/default/smilies/wink.png" alt=";-)" class="smiley" /> Les projets influents montreront la voie en quelque sorte.</p>interfaces == interopérabilité ? - Cyranourn:md5:5f9a96326ed763395a7b51f95e7afe2c2011-10-25T15:55:04+02:002011-10-25T15:26:50+02:00Cyrano<p>Idée intéressante s'il en est, mais personnellement, je ne crois pas que je verrai sa mise en œuvre de mon vivant. Ceux qui sont membre de l'AFUP auront peut-être suivi l'échange que je voudrais mentionner parce qu'il illustre assez dramatiquement le problème général.</p>
<p>Un membre s'est interrogé à propos des impacts de la migration d'une application montée avec Symfony 1.x vers Symfony 2.x. Tous se sont accordés à lui répondre qu'il allait falloir pratiquement tout ré-écrire, on ne parle plus de migration mais de refonte majeure. Là, on a pas l'idée générale des interfaces au sein d'un même éditeur pour deux versions majeures d'un même framework ... qui ne sont en fin de compte pas les mêmes. S'il avait été question de passe de Symfony a ZF ou Cake ou Hoa ou que sais-je encore, ça aurait été plus facile à admettre, mais d'une version à une autre...</p>
<p>À mon avis, le jour où on verra l'ensemble des éditeurs s'entendre sur des interfaces communes n'est pas près d'arriver. Mais j'en viens aussi à me dire que c'est peut-être précisément ce genre d'exemple qui a inspiré le sieur Lukas. Ça reste vraiment très séduisant et ça pourrait ouvrir la porte à des formes de compétitions des plus intéressantes : partir d'une interface pour traiter un type de problème donné et voir les différentes implémentations qui en sortiraient un peu partout. on pourrait voir chacun se construire des bibliothèques en choisissant les implémentations les plus performantes/stables/solides/etc (rayer les mentions inutiles ou ajoutez les vôtres) : à terme, chacun se concentrerait exclusivement sur son code métier sans mettre le nez dans les bibliothèques...</p>
<p>Or l'idée des interface ne serait pas nécessairement très difficile à élaborer. On utilise tous plus ou moins certains packages pour des traitements récurrents et on a tous besoin de certaines fonctionnalités. l'interface, c'est quand même aussi à la base une convention de nommage. En faisant un peu le tour de l'existant à travers les différents framework et les différentes implémentations existantes, il devrait être possible d'en extraire une ligne directrice autour de laquelle construire différentes interfaces.</p>
<p>Avec ce système un site comme phpclasses.org aurait un peu moins l'air du marché aux puces des classes PHP,... on peut toujours rêver ...</p>interfaces == interopérabilité ? - Julien Breuxurn:md5:e4360307906230a075497ad8a5033d702011-10-25T14:55:41+02:002011-10-25T14:37:26+02:00Julien Breux<p>Dans un premier temps, je dirai allons vers l'idée de Lukas.<br />
Mais de façon neutre, je pense alimenter le sujet lors d'une rencontre car il y'a énormément d'enjeux d'avenir sur le formalisme de l'interopérabilité.<br />
C'est un bon débat ceci dit.</p>interfaces == interopérabilité ? - Olivierurn:md5:bc5c0fcedf4c0306da89b67890b4aedd2011-10-25T14:39:27+02:002011-10-25T13:40:05+02:00Olivier<p>Ça me rappelle un peu J2EE avec toute sa séries de spécs (et donc d'interfaces) qui décrivent comment faire les templates (JSP), traiter les requêtes HTTP (Servlet), la persistence (JPA), l'envoi de mail (JavaMail)...</p>
<p>Au final, beaucoup de ces spécs ne sont pas utilisées car il existe souvent des frameworks non standards, mais mieux fichus (ex : hibernate, spring).</p>
<p>Enfin, j'ai l'impression que le principal intérêt d'une standardisation n'est pas de permettre de switcher d'implémentation au sein d'un même projet (ça n'arrive quand même pas très souvent), mais plutôt de capitaliser sur une expérience plus pérenne (les standards changent moins vite que que les frameworks en théorie <img src="/themes/default/smilies/smile.png" alt=":)" class="smiley" /></p>interfaces == interopérabilité ? - Jawadurn:md5:a5d574b60adbf03061c0b8a91dc96cc32011-10-25T14:04:57+02:002011-10-25T13:39:45+02:00Jawad<p>Cela se rapproche beaucoup du langage Java où on distingue beaucoup plus specs et implémentation. Ce qui a du bon parfois, comme tu l'expliques très bien dans ton article !</p>
<p>Par ailleurs, qu'est-ce qui empêche de proposer ces interfaces en dehors du "circuit officiel PHP" ? Pourquoi Lukas veut-il nécessairement les incorporer à l'interpréteur ?</p>interfaces == interopérabilité ? - Ivan Enderlinurn:md5:bb64326d6fbcbfea4b5d54d452954a292011-10-25T13:58:52+02:002011-10-25T13:39:45+02:00Ivan Enderlin<p>Hey :),</p>
<p>Merci pour le lien, sympa !<br />
Dans Hoa (pour en parler un p'tit peu), il y a un effort très conséquent sur les interfaces justement. Par conséquent, c'est pour ça que l'on peut remplacer n'importe quel flux (fichier, socket, XML …) par un autre flux sans que le fonctionnement du code ne soit impacter. Ou autre exemple, le maximum de bibliothèques sont partagées ou réutilisées, ce qui implique que si un développeur veut écrire un « hack » (comprendre, une modification), alors il sera disponible partout à moindre coût de maintenance. Si on mutualise les efforts de maintenance, on mutualise également les efforts de tests et tout ce que ça implique.<br />
Dans Hoa il y a une volonté forte d'abstraire les bibliothèques et leurs utilités. C'est une démarche longue et fastidieuse mais qui permet d'automatiser plus de choses qu'on ne pourrait le croire. Je ne me spoil pas plus, venez à la conférence du PHPTour fin novembre organisée par l'AFUP à Lille, et vous en saurez plus ;-).</p>Mort de PHP6 + 90 jours - desfrenesurn:md5:227c7994ec8211fe997a5fb0484f013d2010-06-11T16:43:44+02:002010-06-12T09:16:47+02:00desfrenes<p>@Niko on pourrait aussi virer les accolades ? <img src="/themes/default/smilies/wink.png" alt=";-)" class="smiley" /></p>Mort de PHP6 + 90 jours - Renaudurn:md5:6709593421b8ffa62c0afeb7e8d7d1842010-06-11T15:39:10+02:002010-06-11T15:11:51+02:00Renaud<p>Comme d'habitude, billet très intéressant, très bien expliqué... bref parfait.</p>
<p>Continue de nous informer de ce qui bouge, je suis vraiment fan <img src="/themes/default/smilies/smile.png" alt=":)" class="smiley" /></p>Mort de PHP6 + 90 jours - Jorisurn:md5:ff3dcfe2817f68587a98f7b623a9f9a12010-06-11T11:13:34+02:002010-06-11T11:32:52+02:00Joris<p>Rooh mais c'est magique le dé-référencement \ o / !<br />
Par contre, je serais plus d'avis de garder :</p>
<p>$result = (new ResultMaker())->getIt();</p>
<p>Qui cerne mieux le concept je trouve.</p>Mort de PHP6 + 90 jours - NiKourn:md5:f76f1e87f28e056c25604742d7099de72010-06-11T11:00:04+02:002010-08-19T13:50:59+02:00NiKo<p>Bien bien bien.</p>
<p>Bon maintenant à quand $foo = 'a', 'b' et $bar = new Foo()->getBar() ?</p>
<p>Allez, je taquine php, ça va dans le bon sens.</p>Mort de PHP6 + 90 jours - oxmanurn:md5:ab56baa5fb9411fd0e90158f08ffd2fe2010-06-11T10:35:37+02:002010-06-11T09:57:43+02:00oxman<p>Ah cool le "déréférencement" de tableau <img src="/themes/default/smilies/smile.png" alt=":-)" class="smiley" /></p>Mort de PHP6 + 90 jours - Revlisurn:md5:eade921a16c29767f255dc72be0258132010-06-11T10:30:40+02:002010-06-11T09:57:43+02:00Revlis<p>$result = new (ResultMaker()->getIt());<br />
// or<br />
$result = (new ResultMaker())->getIt();</p>
<p>Pour moi les deux syntaxe me paraissent, OK, mais désignent 2 choses différentes<br />
$result = new (ResultMaker()->getIt()); permetrait d'instancier une nouvelle class dont le nom est retourné par ResultMaker()->getIt()</p>
<p>Code associé<br />
function ResultMaker() {</p>
<pre>return new A();</pre>
<p>}<br />
class A{</p>
<pre>function getIt() {
return 'B';
}</pre>
<p>}<br />
class B {<br />
}<br />
en gros, ce code pourrait s'ecrire de différente manbières :<br />
$result = new (ResultMaker()->getIt());<br />
ou $result = new ((new A())->getIt());<br />
ou $result = new ('B');<br />
ou $result = new B()</p>
<p>la seconde $result = (new ResultMaker())->getIt(); permet d'appeler la fonction getIt de la classe ResultMaker directement après sont instenciation, un peut comme<br />
$c = new ResultMaker();<br />
$result = $c->getIt();</p>