Donc comme je l'ai déjà dis, la plupart des modifications effectuées sur le trunk sont des consolidations.
Il y a tout d'abord le lot habituel de corrections de bug.
Les bugs #52926 et #52944 de l'extension zlib, le bug #52947 de l'extension openssl, les bugs #52891 et #45921 de mysqli, les bugs #52891 (oui, le même, ce n'est pas une erreur) et #48082 de mysqlnd, les bugs #52929 et #52944 des filtres ainsi que le bug #52909 des archives phar sont maintenant soit partiellement, soit totalement corrigés.
Je dis partiellement car le bug #52909 n'est en fait pas du tout corrigé, et je suis bien placé pour le savoir.
En effet, c'est moi qui l'ai découvert, et j'ai donc suivi son évolution de très prés.
Le problème est le suivant.
Au niveau du code source C du langage, les objets \phar et \pharData se partage le même constructeur, ce qui fait que la méthode \reflectionMethod::getParameters() de PHP ne sait pas renvoyer les arguments de \phar::__construct() puisqu'elle retourne la liste des arguments de \pharData::__construct().
En effet, \reflectionMethod::getParameters() se base sur une structure spécifique insérés dans le code C de PHP pour fonctionner, et le cas où une même fonction C est partagée par deux fonctions PHP différentes n'est pas gérable par ce système.
Dans un premier temps, le rapport de bug a été fermé, même si le problème était bien reconnu comme tel, car il n'était sois-disant pas possible techniquement de le résoudre.
Évidemment, je n'ai pas été d'accord avec cette décision, et je suis donc allé discuté du problème sur le canal IRC des contributeurs.
Après quelques minutes de discussion, et avec l'appui de Pierre Joye et de quelques autres, je suis parvenu à faire ré-ouvrir le rapport de bug.
Le code C concerné sera donc réécrit afin de résoudre proprement le problème.
Et si j'insiste sur ce point particulier, c'est que c'est la première fois que j'obtiens un tel résultat de cette manière, surtout dans le cadre d'un rapport de bug, et je dois dire que j'ai été très agréablement surpris, puisqu'il n'y a pas si longtemps, je me serais fais proprement jeter.
Il semblerait donc que les contributeurs soient plus ouvert à la discussion, et je ne peux que m'en féliciter et les remercier, surtout s'il ne s'agit pas d'un cas isolé, ce qui reste à confirmer.
Pour en revenir à notre sujet de départ, le reste des modifications effectuées sur le trunk sont des optimisations internes au Zend Engine, la résolution de problèmes rencontrés à la compilation des sources, et également des optimisations au niveau des tests unitaires afin de les rendre plus génériques et indépendants de la plate-forme sur laquelle ils sont exécutés.
Enfin, le fichier NEWS a fait son arrivé dans le trunk.
Ce fichier récapitule sous une forme synthétique l'ensemble des modifications effectuées sur le trunk depuis la mort de PHP 6 et le moins que l'on puisse dire est que les contributeurs n'ont pas chômés.
Au niveau de la liste de diffusion des contributeurs internals@, justement, comme je l'ai déjà indiqué précédemment, le calme est revenu après les débats virulents qui se sont déroulés au sujet de l'implémentation des annotations.
Comme d'habitude dans ce genre de cas, les discussions se sont éteintes d'elles-mêmes sans qu'aucune décision claire ne soit prise, mais je pense qu'elles reprendront dès qu'une évolution technique sera diffusée, soit dans le sens de la notation docblock, soit dans le sens de la RFC d'origine des annotations.
Cela a d'ailleurs été le cas pour un tout autre sujet, puisqu'il concerne l'utilisation de {} et [] pour accéder à un caractère d'une chaîne.
Au final, il semblerait que les deux notations restent possibles à l'avenir, mais que le traitement de la syntaxe utilisant {} sera optimisé.
Il devrait donc toujours être possible avec la prochaine version majeure de PHP d'écrire $str[42] et $str{42}, ce qui ne manquera pas de ravir les fans de la cohérence au sein du langage, cela dit bien évidement sans la moindre ironie.
D'ailleurs, en parlant de cohérence, le problème de la méthode magique __invoke(), que j'ai déjà évoqué sur ce blog, a fait une apparition fugitive, et il a reçu la réponse habituelle.
Enfin, un patch a été proposé pour simplifier l'utilisation de l'extension snmp en permettant de passer un tableau d'OID en argument des fonctions snmpget() et snmpgetnext(), et il semble en bonne voie pour être accepté.
Cette récapitulation est maintenant terminée, vous pouvez reprendre une activité normale.
13 réactions
1 De Eric - 30/09/2010, 11:32
> puisqu'il n'y a pas si longtemps, je me serais fais proprement jeter.
Rectificatif : tu t'*es* fait jeté. Mais en discutant avec des relations personnelles qui ont de l'influence dans le core, tu as réussi à faire réouvrir ce qui n'aurait jamais du être fermé.
On peut considérer qu'il y a du mieux, mais il n'y a pas non plus de quoi danser. La réaction de base reste un "c'est comme ça" ou un "ce n'est pas possible", et une fermeture du ticket. (pour les vieux, à l'époque on disait ça de l'unicode, des espaces de noms, du LSB, et de plein de choses qui ont été implémentées depuis).
La réponse au __invoke() en est très symptomatique. Il est évident que c'est une incohérence du langage. Visiblement cette incohérence pose problème à plus d'un. On peut le corriger (quand c'est possible), le reconnaitre, ou le rejeter. On choisit la dernière alternative.
-
Sinon moi j'adore suivre l'histoire de { } et avec des popcorn. Et c'est là qu'on voit que le processus de décision est parfois défaillant (même si je n'ai pas de formule magique à proposer pour faire mieux, c'est un constant, pas une critique).
Fut un temps où pour les chaînes de caractères provoquait une erreur et il fallait utiliser { }. Puis peu de temps après { } renvoyait un "deprecated" dans les erreurs et il fallait utiliser . Ca a été (rapidement) modifié suite aux retours négatifs de la communauté et on peut utiliser les deux désormais. Maintenant il est clair qu'on va garder les deux. Si { } devient plus optimisé on peut considérer que c'est désormais çe dernier qu'il faut utiliser.
Un pas en avant, un pas en arrière, etc.
Ce qui est encore plus sympa, c'est que si on implémente unicode à l'avenir (j'y crois encore, je veux y croire), on va avoir droit à un super débat sur la pertinence d'implémenter et {} pour itérer à travers les octets, à travers les code point unicode, ou à travers les symboles (e` étant è). Il va y avoir moultes discussions et je ne donnerai pas ma main au feu qu'on ne va pas dissocier la sématique de (octets) et { } (caractère)
-
Sinon, au risque de paraitre encore très négatif alors que je ne le suis pas comme ça, cette phrase de @internals caricature très bien la façon de fonctionner qu'a eu le groupe à un moment :
"One opinion is it should remain deprecated but without an E_DEPRECATED error, but I'm unsure how that makes sense. To me that says it's not deprecated, but rather, is discouraged (but still for unknown reasons)."
One opinion => rien n'est décidé, on ne sait pas qui décide et comment
remain deprecated but without an E_DEPRECATED => tout et son contraire, on n'ose pas aller jusqu'au bout et on prend des décisions incohérentes
not deprecated, but rather, is discouraged => nuances de salon pour contourner le problème sans le régler
but still for unknown reasons => je ne commenterai même pas tellement la fin me fait rire
2 De Julien Breux - 30/09/2010, 11:46
$str42 || $str{42}
Arfff, donc PHP n'a pas pour vocation future de s'harmoniser et prendre en cohérence
@Frédéric
Encore une fois, merci
3 De thomas - 30/09/2010, 12:26
Vraiment passionnant ce post. Merci.
4 De Korri - 30/09/2010, 14:36
Merci pour tes articles qui me motivent de plus en plus à me mettre au python !
Sinon petite erreur il me semble : \pharData;;__construct(), à ma connaissance on ne peut pas utiliser de ";" (à moins que ça ne soit une nouvelle syntaxe alternative ^_^).
5 De mageekguy - 30/09/2010, 16:39
@Korri :Dommage, faire switcher de PHP vers un autre langage n'est pas du tout l'objectif de cette série d'articles, bien au contraire.
Il ne faut pas laisser des petits points négatifs occulter le grand nombre de nouveautés et de modifications positives pour le langage.
PHP a des travers, des défauts, et je suis le premier à le regretter, mais il évolue en conséquence, certes lentement, mais il le fait et je pense qu'il faut lui laisser sa chance, d'autant que tous les langages ont ce type de défaut.
6 De metagoto - 30/09/2010, 17:06
A propos du bug #52909, \reflectionMethod::getParameters() ne se base pas sur les commentaires spéciaux insérés le code source C. Ces derniers ne servent, de manière programmatique, qu'au système de documentation de php. Le mécanisme de reflection dans php est moins "magique" (dans le sens de se reposer sur des meta info). Il faut dérouler des séries de macro ZEND_BEGIN_ARG_INFO / ZEND_ARG_INFO pour chaque signature de fonction et chaque argument. Quand il s'agit de récupérer la default value d'un argument, là le système inspecte carrément les séries d'opcodes concernés.
Un seul "args info" est responsable des constructeurs de Phar et PharData car ces deux classes partagent les mêmes fonctions au niveau des sources. Au final ce n'est pas un bug de la reflection, mais plutôt un problème de design de phar.
7 De mageekguy - 30/09/2010, 17:20
@metagoto : J'ai corrigé le billet en conséquence, merci.
D'ailleurs, si tu sais ou trouver de la documentation au sujet de ZEND_ARG_INFO, je suis preneur.
J'ai vu passer un lien sur IRC il y a peu de temps, mais je n'arrive pas à remettre la main dessus.
8 De metagoto - 30/09/2010, 19:06
@mageekguy
Je n'ai pas de liens spécifiques. C'est assez "simple" au niveau des sources de php (pour ce point en tout cas).
Les macro sont définies dans zend_API.h. Le but est de construire un tableau static dont chaque ligne correspond à un argument (usage notamment d'operateurs de "stringization" du preproc). Entre autres choses, php associe à chaque fonction (ou méthode) un lien vers ce tableau sous forme de pointer vers une struct zend_arg_info. La reflection récupère et opère sur ce genre d'info quand on lui présente une fonction à analyser.
9 De Nicolas Laforêt - 01/10/2010, 08:26
Merci pour le bilan. Avec tes billets j'ai pris l'habitude d'aller jeter un œil a @internals (tu vois tu ne motive pas tout le monde a switcher
) ...
C'est dommage que les discussions tombent dans le vide comme ca ...
Une bonne roadmap, un but a l'équipe, pour se motiver a sortir de nouvelle version de PHP. Quand on voit que php 5.1 date de 2005 .... PHP a perdu beaucoup de temps, et le rattraper serait faisable avec un peu de "bonne pression" sur les contributeurs. Un but a atteindre serait peut être moteur pour tout le monde, se réunir autour d'un objectif, c'est peut-être ce qu'il manque ?
10 De whyNot - 01/10/2010, 08:31
mageekguy a écrit:
"Dommage, faire switcher de PHP vers un autre langage n'est pas du tout l'objectif de cette série d'articles, bien au contraire"
Et pourtant c'est bien ce qui se passe... je rejoins +100 Korri, suis également en train de switcher sur Python.
(Jelix oui, mais manque de communauté).
C'est + difficile qu'il n'y paraît (nouveaux paradigmes à bien intégrer) mais aussi gros soulagement à se 'désintoxiquer' du php (ça vous tord vraiment la tête ce langage).
Prochaine étape, l'apprentissage de django, parce que Symfony, ZFwk, Cake, CIgniter... ça n'est jamais passé
Les offres d'hébergement Python sont encore limitées (pour combien de temps encore...), c'est la seule limite que je vois à une adoption massive du langage (ironie du sort, qui aurait pu penser cela il y a 10 ans ??).
Merci en tout cas pour vos articles qui confirment en tous points mon ressenti.
11 De Laurentj - 01/10/2010, 10:40
@whynot : meuh non, il n'y a pas de manque de communauté sur jelix :-). Le principal dans une communauté d'utilisateurs d'un logiciel, ce n'est pas le nombre, mais sa réactivité, et l'ambiance qu'il y a
Et on essaie d'être réactif au maximum (sur IRC ou le forum). Il y a toujours quelqu'un pour répondre sur IRC ou le forum. Le projet est toujours vivant, évolue tout les jours, utilisé par de plus en plus de gens (y compris des grosses boites). Le seul souci est qu'on manque de moyen pour faire connaitre un peu plus le framework.
Viendez nous rejoindre et nous aider !
12 De Armand - 02/10/2010, 00:27
@mageekguy Pour info, le livre "Extending and Embedding PHP" de Sara Golemon, bien que commençant à dater, explique bien toutes les macros de base du fonctionnement interne de PHP. Il y aussi quelques articles sympa sur son blog http://blog.golemon.com
13 De mageekguy - 02/10/2010, 08:39
@Armand : Je cherche une référence au sujet de ces macros sur Internet pour mettre un lien dans le billet, en ce qui concerne les macros, j'en connais déjà pas mal, même si je ne suis pas encore un expert.
Merci en tout cas d'avoir parlé du livre de Sara, qui est pratiquement l'une des seules ressources disponibles sur le sujet.