mars
2010
Un article de doctorrock
Tentative rapide de résumé :
- PHP6, ancien trunk, n’existe plus : il s’agit de la branche FIRST_UNICODE_IMPLEMENTATION
- Le code de PHP5.3 actuel est devenu le trunk, PHP5.3 ne verra plus de nouvelles fonctionnalités : « bug fixes only » (stable code)
- Un ‘trunk-dev’ va faire son apparition : ca sera la base de PHP5.4 ou PHP6, mais c’est une copy du nouveau trunk (rien à voir donc avec unicode)
- PHP 5.2 est arrêté : il a le statut « security fixes only »
- Le mécanisme Unicode actuel de « feu » PHP6 n’est pas correct (UTF-16), trop long à développer, nécessite des conversions internes permanentes, cassures de compatibilité, etc… (détails)
- Un nouveau mécanisme doit être trouvé (extension de mbstring, class String…)
- Ce nouveau mécanisme est développé dans la branche FIRST_UNICODE_IMPLEMENTATION , Rasmus a demandé à ce que le problème global soit découpé en sommes de petits problèmes, et à ce que tout le monde réfléchisse ensemble pour trouver bien sûr « la » meilleure solution (détails, lisez toutes les réponses pour l’histoire complète : conseillé!)
La branche trunk-dev actuelle accueillera des nouveautés comme ,le type hint étendu aux scalaires, un nouveau mécanisme d’output buffering, la réutilisation horizontale (traits) dans le modèle objets, etc… De là naitra un probable PHP5.4 ou pourquoi pas un PHP6 (rien à voir avec le support Unicode donc)
PHP5.2 va être arrêté incessamment sous peu (bug fix seulement). Il va falloir songer à migrer si ce n’est pas déja le cas, la migration n’étant pas si difficile que celà.
On notera donc une machine arrière : le développement du PHP6 que nous connaissions tous (de près ou de loin) est aujourd’hui officiellement stoppé. Le mécanisme est trop lourd, trop long à développer. Le PHPGroup réfléchit maintenant à une implémentation plus légère, ce qui laisse à penser la fin de l’idée d’un support total de Unicode. Cette implémentation sera donc plus rapide, plus fléxible, mais moins complète, alors qu’aujourd’hui on ne sait rien à son sujet (tout est ouvert). Suivez les mailing-lists (internals en particulier) de près pour la suite.
Voila des idées qui font bouger! Tout le monde l’admet enfin : on s’enlise et ça sent pas bon. C’est surtout les développeurs : ils devaient jusqu’à présent développer dans un trunk à base d’Unicode (de l’ex PHP6) et porter leurs modifs dans la branche 5.3, un casse-tête qui a failli couté une release ratée. D’autant plus que l’avancée sur Unicode et le nouveau moteur ZendEngine3 était au point mort depuis trop longtemps.
2 Commentaires + Ajouter un commentaire
Commentaires récents
Archives
- novembre 2010
- août 2010
- juillet 2010
- juin 2010
- mai 2010
- avril 2010
- mars 2010
- février 2010
- janvier 2010
- décembre 2009
- novembre 2009
- octobre 2009
- septembre 2009
- août 2009
- juillet 2009
- juin 2009
- mai 2009
- avril 2009
- mars 2009
- février 2009
- janvier 2009
- décembre 2008
- novembre 2008
- octobre 2008
- septembre 2008
- août 2008
- juillet 2008
- juin 2008
- mai 2008
- avril 2008
- mars 2008
- février 2008
- janvier 2008
- décembre 2007
- novembre 2007
- octobre 2007
- septembre 2007
- août 2007
- juillet 2007
- juin 2007
- mai 2007
- avril 2007
- mars 2007
- février 2007
Le support d’unicode, ça me semble vraiment optionnel vu que de toutes façon en sorti on a déjà pas de problème la dessus.
Par contre, le multithread est juste impossible en php (plateform independant), et vu le architecture des processeurs futures (et actuelle même) ça me semble vraiment crucial. Je vais devoir me tourner vers python !!!
Un sacré revirement de situation. Mais quel gâchis pour en arriver jusque là! Et je ne parle pas du support unicode, mais des bons proposals, à l’instar des traits, qui sont restés en stand-by pour certains pendant des années à cause de choix douteux de branches et de politiques dans leur VCS.
Pour unicode, à mon avis, il ne sont pas sortis de l’auberge! Je crains que toute solution alternative et plus light (l’école de Rasmus) ne soit vouée à l’échec à long terme, car rendue obsolète.