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.
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.
Pour parler concrétememnt, s'il existait par exemple une telle interface pour les ORM tel que Propel ou Doctrine, passer de l'un à l'autre au sein d'un projet utilisant Symfony 2 deviendrait trivial, et à la rigueur, le développeur n'aurait même pas besoin de connaître la technologie sous-jacente utilisée.
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.
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.
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.
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.
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.
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.
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 fait maison
de bout en bout.
Les développeurs ont en effet une furieuse tendance à être insatisfait des outils qu'ils ont à leur disposition, moi le premier.
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.
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.
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.
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.
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.
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é.
Cependant, rien ne dit que demain un outsider 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.
De toute façon, la compatibilité et l'interopérabilité sont loin d'être un objectif majeur dans le monde de l'informatique.
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.
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.
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 codec vidéo ou l'annonce récente de Dart n'en sont que des exemples.
Le fait que la neutralité du Net, 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.
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.
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.
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 PHP Standards Working Group.
Il regroupe en effet, je cite, le gratin des lead developers
des "grands" frameworks que sont Zend Framework, Symfony, PEAR, Solar, j'en passe et des meilleurs.
Il est à l'origine de la proposition dite PSR-0 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 portable
.
La RFC 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 internals@.
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 PSR-0 directement au niveau du moteur de PHP.
Cependant, ceux qui ont suivi le lien 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...
Il faudra de plus obtenir un conscensus sur le sujet auprès des développeurs de PHP, 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.
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.
Enfin, certain 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.
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.
Cependant, je suis également très curieux de connaître votre avis sur ce que j'appellerais dorénavant l'idée de Lukas
!
7 réactions
1 De Ivan Enderlin - 25/10/2011, 13:58
Hey :),
Merci pour le lien, sympa !
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.
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 ;-).
2 De Jawad - 25/10/2011, 14:04
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 !
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 ?
3 De Olivier - 25/10/2011, 14:39
Ç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)...
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).
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
4 De Julien Breux - 25/10/2011, 14:55
Dans un premier temps, je dirai allons vers l'idée de Lukas.
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é.
C'est un bon débat ceci dit.
5 De Cyrano - 25/10/2011, 15:55
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.
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...
À 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...
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.
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 ...
6 De metagoto - 25/10/2011, 18:00
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).
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.
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 Les projets influents montreront la voie en quelque sorte.
7 De MathRobin - 25/10/2011, 23:58
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.