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 !