Et il s'est passé sur les dix jours qui viennent de s'écouler l'inverse des dix jours précédents, puisque l'activité sur le trunk a été relativement réduite, et qu'à contrario, il y a eu pas mal d'échanges sur internals@, la liste de diffusion des contributeurs.
En effet, après le coup d’accélérateur de la période précédente, le rythme des modifications sur le trunk, qui contient le code source de la prochaine version majeure de PHP, s’est à nouveau ralenti, avec seulement un peu plus de 25 modifications effectuées, contre plus d’une cinquantaine sur la période précédente.
Et parmi ces modification, il y les corrections correspondant aux bugs #48465, #44989, #54423, #54423, #54454, #53037, #54065 et #54372.
Par ailleurs, la demande #54459 a été implémenté dans le langage et la fonction range() fonctionnera dorénavant correctement le pas utilisé pour calculer les valeurs à insérer dans le tableau est un nombre à virgule flottante.
Le reste des modifications n'est pas plus intéressant, puisqu'il s'agit pour l'essentiel d'optimisation et de consolidations visant à rendre le langage plus fiable et plus efficace.
Heureusement, la liste de diffusion des contributeurs, internals@, a été un peu plus intéressante.
Une discussion au sujet de certaines fonctions relatives aux chaînes de caractères a en effet pas mal dérivée et a permis de découvrir que Dieu Rasmus Lerdorf réfléchit à une façon d'implémenter une interface objet au chaîne de caractères et aux méthodes.
Cependant, pour l'instant, il n'a fait qu'y réfléchir, et le chemin sera encore long d'ici à ce qu'une telle fonctionnalité soit intégrée à PHP.
Sébastian Bergmann, le créateur de PHPUnit, a de son côté proposé un patch qui permet de limiter la profondeur d'analyse de la fonction debug_backtrace() via l'ajout d'un argument.
Il a été accueilli favorablement par les contributeurs, et en conséquence, il devrait être intégré dans le trunk, et la fonction debug_print_backtrace() devrait également à plus ou moins court terme bénéficier de cette fonctionnalité.
Enfin, une discussion est en cours pour ajouter le support implicite de isset() ou empty() au sein de l'opérateur ternaire.
Grâce à cette fonctionnalité, il serait possible d'écrire par exemple le code suivant :
<?php $users = array('login' => 'mageekguy'); echo $users['login'] ?: 'Login not set.' . PHP_EOL; echo $users['password'] ?: 'Password not set.' . PHP_EOL; ?>
En effet, il ne générerait plus d'erreur de type NOTICE lors du second appel à echo.
Ce bulletin d’information est maintenant terminé, vous pouvez reprendre une activité normale.
4 réactions
1 De Mathieu ROBIN - 08/04/2011, 09:24
Du coup, j'ai une question qui me trotte. La prochaine version, ça sera quoi du coup? 5.4, 6 quand même ou 7?
J'aime beaucoup l'idée du support de isset() et empty() dans les ternaires, abusant de cette structure dans mon code...
2 De mageekguy - 08/04/2011, 09:28
@Mathieu ROBIN : Le nom de la version n'est pas encore choisi, mais il y a de fortes chances que ce ne soit pas 6, et 5.4 revient régulièrement, mais ça ne correspond pas à une majeure.
3 De Guile - 08/04/2011, 14:28
Je suis content d'apprendre ça : le debug_backtrace limité peut être d'une très grande utilité, tout comme la nouveauté du ternaire. Néanmoins, y a-t-il une précision sur ceci? Car, de tête, faire un test du style
lève un warning quand la clé n'existe pas, ce que la fonction empty permet d'éviter.
Alors la ligne
va-t-elle lever un warning ?
Je cherche également un moyen propre et court d'écrire l'équivalent SQL de isnull(variable, 'vide').
Soit une fonction au prototype :
Ou bien (d'où le fait que j'en parle ici) avec un opérateur "ternaire combiné" par exemple :
ou moins joli
Ces trois exemples affecteraient la valeur $defaultvalue quand empty($variable) == true. Soit l'équivalent de :
if (true === empty($variable)) { $variable = $defaultvalue; }Vous en pensez quoi ?
4 De Matthieu - 08/04/2011, 19:23
« Sébastian Bergmann, le créateur de PHPUnit, a de son côté proposé un patch qui permet de limiter la profondeur d'analyse de la fonction debug_backtrace() via l'ajout d'un argument. »
YES ! Enfin ! Ça permettra enfin aux implémentations de classes "Friend" d'être un peu moins gourmandes en ressources, cf : http://blogs.codes-sources.com/madm... Je me souviens d'ailleurs d'un échange plus vieux à propos de cette fonctionnalité de classes "Friend", et Sebastian était intervenu en proposant une solution de ce genre, qui permettrait de les implémenter de manière plus propre, sans toutefois imposer le concept de classe Friend au langage.