Le bug #53632 a donc été résolu et sa correction est d'ailleurs à l'origine de la sortie des versions 5.3.5 et 5.2.17 du langage.
Cependant, ce n'est pas le seul bug à avoir été corrigé puisque les bugs #53466, #53682, #53503, #56349, #53630, #53729, #53717 et #53551 ont été résolus.
Dans un tout autre registre, la méthode \regexIterator::getRegex() a été implémententée, conformément à la demande #53659, et son auteur a publié sur son blog un exemple d'utilisation.
Cette période a d'ailleur été faste pour les requêtes en provenance des utilisateurs du langage, puisque trois autre demandes ont été acceptées, à savoir #47802, #53684, #53466 et #39847.
Les directives error_prepend_string et error_append_string ne font donc dorénavant plus appel à la balise HTML <font />, dépréciée depuis 1999.
De plus, l'encodage des caractéres est maintenant supporté dans le DSN du pilote MySQL de PDO, et les fonctions mysqli_fetch_[field|fields|field_direct] retourne maintenant le nom de la base de données d'où sont extraits les champs concernés.
Et pour en finir avec les bases de données, la méthode \sQLite3Result::columnType() retourne maintenant false lorsqu'il n'y a plus d'enregistrements à récupérer.
La méthode \regexIterator::getRegex()n'est pas la seule à avoir été ajoutée au langage, puisque suite à une discussion commencée durant la période précédente sur la liste de diffusion des développeurs, la méthode\splObjectStorage::removeAllExcept() a été ajoutée à la version de développement de PHP.
La méthode trait_exists() a également été ajoutée, afin de pouvoir vérifier l'existence d'un trait à l'exécution, de la même façon que class_exists(), qui retourne dorénavant et logiquement false lorsqu'elle est utilisée sur un trait.
Et en parlant des traits, ces derniers ont été à l'honneur sur la liste de diffusion des contributeurs au langage, internals@, puisqu'ils ont été le sujet de la majorité des discussions.
Il faut dire que la liste n'a pas été des plus actives, sans que je puisse en donner une explication.
Dans tous les cas, les traits semblent passionner la communauté des développeurs, même s'ils semblent avoir quelques difficultés à en appréhender les subtilités.
De plus, la question de l'implémentation des traits au sein des fonctionnalités d'introspection de PHP fait toujours débat, et n'a toujours pas de réponse.
Stefan Marr, l'auteur de l'implémentation des traits dans PHP, a d'ailleurs saisi l'occasion pour demander une planification pour la sortie de la prochaine version du langage, afin qu'il puisse organiser au mieux son temps, mais sa requête n'a pas reçu de réponse pour le moment.
Au niveau des RFC, Derick Rethans a proposé d'ajouter un argument à la fonction debug_backtrace() afin de pouvoir désactiver le traitement des arguments au niveau de la pile d'exécution, et sa demande reçoit pour le moment un accueil favorable.
Enfin, il y a eu le lot habituel de corrections et d'optimisation, aussi bien au niveau du moteur du langage que de sa compilation, qui devrait s'effectuer plus proprement.
Et pour terminer sur une note d'humour, pour ceux qui se demanderaient comment participer au développement de PHP, l'un des contributeurs, Chad Fulton, a donné le mode d'emploi officieux, et je peux dire que, de part mon expérience, c'est, et de loin, le meilleur que j'ai pu lire à ce jour.
Cette rétrospective est maintenant terminée, vous pouvez reprendre une activité normale.
10 réactions
1 De Eric - 17/01/2011, 06:50
Juste une coquille: il manque un s à Rasmus.
J'en profite pour te remercier de nous donner régulièrement ces informations, c'est toujours très intéressant.
2 De mageekguy - 17/01/2011, 08:53
@Eric : Coquille corrigée, merci, et de rien.
3 De Steuf - 17/01/2011, 11:22
Et moi je rêve de pouvoir ordonner les appels aux destructeur ou que ceux-ci soient appeler dans un ordre une peu plus "intelligent".
4 De mageekguy - 17/01/2011, 13:19
@Steuf : ?
5 De Steuf - 17/01/2011, 13:31
Bah simplement que le GB fait des appels aux destructeurs des objets dans l'ordre que les constructeurs sont apparus. Un peu plus intelligent pour moi veut dire : Quand dans un destructeur de l'objet B, C, D je fais référence à l'objet A (Notamment en utilisant l'objet A avec un singleton), quelque soit les ordres des appels, pour moi, A ne doit être détruit qu'après que B,C,D soit détruit.. Or le comportement actuel semble que les destructeurs sont appelés dans le même ordre que les constructeur sont appelés, de ce fait il se peut que A (et ses références) soit détruit avant B, C ou D en fonction des ordres des appels.
Alors autant il y a register_shutdown_function qui permet de détruire un objet avant les autres (Enfin ça fait très bidouille quand même), mais ça ne répond pas exactement à la question du "Je veux que l'objet X ne soit détruit qu'après tous les autres". ce qui serait très utile dans le cadre d'un Logger (Et c'est exactement dans ce contexte que le fonctionnement actuel me gêne).
Donc ce que j'aimerais à l'heure d'aujourd'hui en PHP c'est que le GB prenne en compte les référencement pour ordonner correctement les destructeurs des objets, soit qu'il y ait au moins l'inverse de register_shutdown_function pour signier de détruire un objet après tout les autres.
6 De mageekguy - 17/01/2011, 14:06
@Steuf : Le GB est appelé sur une variable lorsque le champ
ref_countde la structure Czvalcorrespondant à la variable est à 0, donc lorsqu'il n'y a plus aucune référence sur l'objet.L'ordre d'appel des constructeurs n'a aucune importance.
Si le comportement que tu obtiens n'est pas celui-ci, il faut que tu incrimines ton code, et non le GB de PHP.
7 De Steuf - 17/01/2011, 14:56
Quand les objets sont dans une instance d'une class pas de problème, il respecte bien les références. Par contre dès que l'on stocke un objet dans une propriété statique c'est là qu'il se plante à mon sens (Une référence qu'elle soit dans une propriété ou qu'elle soit statique reste une référence pour moi) : http://pastebin.com/dzw7nsYw
Ici le résultat va être CCABB, Si on commente la ligne $a = A::getInstance(); ou la ligne C::attachClass($b); , on a CCBBA (le résultat souhaité).
Ce que je vois c'est qu'à partir du moment ou l'instance est mise dans une propriété statique et bien là il ne considère plus la référence à l'Objet A et ne tiens compte que des références "locales" à l'objet.
Personnellement je trouve ce fonctionnement "bizarre" (d'autant plus si c'est intentionnel de la par de php).
8 De mageekguy - 24/01/2011, 23:02
@Steuf : Je savais que j'avais lu quelque chose sur le sujet il n'y a pas très longtemps.
J'ai lu rapidement (je suis fatigué), mais c'est peut être un début d'explication.
9 De Steuf - 28/01/2011, 13:12
J'ai fait le petit test avec ce que j'ai mis sur pastebin en mettant en static dans les méthodes. J'ai eu le résultat souhaité, je me suis dit super (Malgré que je trouve cela très bizarre et assez "sale" de définir du static dans des méthodes, ça me rappel le globals dans les fonctions...). J'ai donc repris la même chose dans mon cas concret... Et patatras ça ne fonctionne pas. Je dois vraiment être tombé sur un cas à la con, j'utilise quelque chose qu'il aime vraiment pas.
En attendant j'ai une rustine plus ou moins propre (register_shutdown_function sur la classe qui pose problème...) je regarderais vraiment en détail quand j'aurais le temps de me tordre l'esprit (ou que quelqu'un d'autre le fasse à ma place :p).
10 De Steuf - 28/01/2011, 16:35
En parlant de truc un peu space en PHP que j'ai presque cru intéressant mais non. C'est la gestion des méthodes statiques http://pastebin.com/NVfYUj8t
On peut en fait appeler une méthode static avec les deux points donc, et de la même façon qu'une méthode classique d'une instance d'une classe. Au début je n'ai pas trop compris, alors je me suis dit que le comportement pouvait changer entre les deux appels en fonction du contexte d'appel. Pour une raison pratique X ça m'intéressait de mettre une méthode en statique mais celle-ci a besoin d'une instance de la classe pour fonctionner (pour faire un raccourci en fait au final à l'écriture). Donc dans la méthode statique je fais une instance de la classe.
Hors en appelant la méthode statique dans une classe déjà instanciée donc avec "->", la méthode recrée une instance supplémentaire. Alors je me suis dit, logiquement comme le contexte d'appel à cette méthode a changé je pourrais faire quelque chose du genre (en gros dans le principe):
if($this)
else
Le fait de pouvoir utiliser la méthode avec "::" et "->" me laissait penser que c'était possible. Et bien non, la méthode en l'appelant avec "->" a strictement le même comportement que si elle était appelé en static avec l'opérateur "::".
D'où la question que je me pose, diantre mais pourquoi une méthode statique est accessible avec l'opérateur "->" ???