Comme à l'habitude, afin de ménager le suspense, je vais commencer par décrire les modifications effectuées sur le trunk.
Il y en a eu soixante-dix, et la majorité d'entre elles sont des corrections de bugs ou de tests unitaires, mais en cherchant bien, il y a une information intéressante.
Ainsi, les bugs #51250, #53440, #29085, #53463, #53492, #53511, #39199, #53512, #53512, #53517, #53515, #26158, #53503, #53425, #53150, #47435, #53530, #53493, #53493 et #48607 ont été corrigés.
Par ailleurs, les demandes utilisateurs #53447, #53457 et #53457 ont été implémentées.
Il sera donc possible avec la prochaine version de PHP d'ouvrir via fopen()
le descripteur de fichier de son choix, comme par exemple ceux disponibles dans /dev/fd
et cela aussi bien sous BSD que Linux et le support de openssl
a été amélioré dans certain contexte d'exécution spécifique.
Les développeurs auront également enfin la possibilité de définir un séparateur de plus d'un caractère pour le séparateur des centaines lors de l'utilisation de la fonction number_format()
.
Des modifications ont également été effectuée afin de faciliter la compilation du langage sous Windows, améliorer les tests unitaires et enfin permettre la compilation de PHP via le même processus que sous UNIX via phpize
.
La gestion des traits, toujours en cours de finalisation, a également été légèrement modifiée.
En effet, suite à une discussion sur internals@, une collision au niveau d'un nom de méthode lors de l'injection d'un trait dans une classe à la compilation du code PHP générera une erreur du type E_COMPILE_ERROR
.
Toujours suite à une discussion sur la liste de diffusion, le paramètre de configuration enable_post_data_reading
a été ajouté, afin de pouvoir empêcher PHP d'effectuer le traitement correspondant à la RFC 1867 sur les données contenues dans $_POST
et ainsi conserver les données brutes.
Le fait de ne pas traiter systématiquement peut en effet être intéressant dans le cas de développement particulier, par exemple dans le cadre de services web.
Cependant, comme je l'ai annoncé en introduction, il y a également eu d'autres discussions sur internals@.
Un vif débat a éclaté suite à la proposition de supprimer le mot-clef global
et la variable $GLOBALS
correspondante.
L'objectif de cette proposition est de rendre PHP moins permissif et d'ainsi éviter le phénoméne du code spaghetti
.
Évidement, pour des raisons qui me semble évidentes et que je ne détaillerai pas, cette suggestion n'a pas du tout reçu un accueil favorable.
Dans un autre registre, le débat concernant la RFC relative à la définition automatique d'accesseurs à la façon de C#, qui a commencé lors de la période précédente, a continué à déchaîné les passions, mais pour l'instant, elle n'est toujours pas acceptée.
Une nouvelle RFC a également été proposée, qui a pour but de généraliser le fonctionnement de l'autoloading
aux fonctions, voir même aux variables.
Elle a pour le moment reçu un accueil favorable, et il est donc possible que cette fonctionnalité soit un jour incluse dans le langage.
Une autre RFC a également été proposée, visant à permettre la définition de l'espace de nommage d'un fichier lors de son inclusion, ainsi que de permettre au développeur de choisir entre les balises <?
et <?php
lors de l'inclusion.
Elle n'est cependant pas encore formalisée dans le wiki correspondant, et n'a reçu encore aucun commentaire.
Par ailleurs, la proposition de rendre le mot-clef function
optionnel semble définitivement enterrée.
De plus, les discussions concernant la gestion du projet PHP en lui-même se sont calmées, ainsi que celles relatives au choix d'un nouveau système de gestion de version.
Sur ce point précis, une RFC récapitulant les débats et proposant une ou plusieurs solutions devrait être prochainement rédigée.
Dans un autre registre, il a été proposé d'empêcher la modification d'un objet \dateTime une fois qu'il a été instancié, mais pour des raisons techniques, cela ne semble pas possible pour le moment, voir même incohérent par rapport au fonctionnement de la classe, du moins au regard de l'implémentation proposée.
Enfin, des discussions sont en cours afin d'éclaircir le fonctionnement des traits, qui ne semble pas encore bien clair à certain.
Cette rétrospective est maintenant terminée, vous pouvez reprendre une activité normale.
14 réactions
1 De Ivan Enderlin - 14/12/2010, 09:11
Hey :-),
Ton lien vers le bug #53457 est faux. Il pointe vers le #53447 :-).
2 De mageekguy - 14/12/2010, 09:33
@Ivan Enderlin : Corrigé, merci.
J'ai vu que je l'avais loupé lors de la relecture du billet, du coup, je l'ai rajouté sans mettre à jour le lien.
Je ne devrais pas écrire de billet en état de fatigue avancé.
3 De MathRobin - 14/12/2010, 10:04
Merci pour ce point!
Ils veulent encore autoriser les short_open_tags pour l'inclusion si j'ai bien compris? J'avoue ne pas être fan. M'enfin c'est comme pour le mot clé function, c'est une question de point de vue personnel.
Pour le reste, comme tu le dis, rien de croustillant.
4 De Julien Breux - 14/12/2010, 10:52
Merci Fredo pour ce petit summary
Oops, une coquille c'est glissée dans la première phrase : "cause d'une emploi du temps"
Merci encore
5 De Pierre - 14/12/2010, 11:07
Merci pour ce récapitulatif que je suis depuis quelques temps.
L'abandon de l'abandon de function est une bonne chose. Je pense que cela aurait porté à confusion et surtout c'est contre productif. Il y a bien d'autres sujets à traiter.
Par contre l'abandon de global ( mais uniquement de global), aurait son interêt. Je ne l'utilise jamais et lorsque j'ai vraiment besoin d'une variable ne se trouvant pas dans le scope, j'utilise $GLOBALS qui est bien plus lourd et surtout se remarque plus vite à la relecture.
Pierre
6 De mageekguy - 14/12/2010, 11:08
@Julien Breux : Coquille corrigée, merci de l'avoir signalé.
Il va vraiment falloir que je fasse plus attention...
7 De MathRobin - 14/12/2010, 17:17
Petite question, tu sais si il a déjà été demandé de remplacer l'usage de libc pour la méthode rand() par celle utilisée dans mt_rand()? Même la doc officielle suggère que le résultat est meilleur et arrive plus vite. En gros l'ancien rand() n'a plus lieu d'être. Il serait peut-être temps de le rénover. Non?
8 De mageekguy - 14/12/2010, 17:20
@MathRobin : Rien vu passé sur le sujet, que ce soit sur IRC ou internals@, mais même si c'était le cas, je pense que c'est très bas en terme de priorité, surtout qu'on parle la en micro-seconde, en terme de performance.
Et puis, ça ne concerne que Windows :).
9 De MathRobin - 14/12/2010, 18:15
Tu sais que j'aime troller sur des questions de performances relativement négligeables
10 De jubianchi - 14/12/2010, 22:13
Je serais peut être le seul à me révolter mais je le fais quand même : un autoload pour les variables et fonctions!!! qu'est-ce qu'il ne faut pas entendre (ou lire :D) !!!
Je trouve déja l'autoload des classe très limite : si on a besoin d'une classe on l'inclue au bon endroit et puis voila... d'accord dans certains cas il est difficile de s'en passé (système de plugin par exemple) mais quel est l'intérêt d'un autoload pour les variables ???
J'espère qu'ils vont nous refuser cette RFC (désolé pour ceux que se sont donné du mal à la rédigée) : on parle de rendre PHP moins permissif et plus propre/lisible et on tente d'introduire de telles choses... mais on va-t-on ?! je me le demande...
En tout cas, comme d'hab, un point très clair, qui permet à ceux (comme @mageekguy) qui ont un emploi du temps super chargé, de suivre régulièrement l'avancée de PHP. Tout simplement : Merci!
11 De mageekguy - 14/12/2010, 23:32
@jubianchi : Rien qu'en terme de performance, et notamment d'empreinte mémoire, l'autoloading de classe a du sens, vu qu'il permet de ne charger en mémoire que ce qui est strictement nécessaire au fonctionnement du script.
L'idée d'avoir le même mécanisme pour les fonctions me parait donc tout à fait intéressante.
Je n'ose imaginer l'intérêt pour un projet tel que Drupal, qui recours très peu à la POO et qui doit être composé d'approximativement 123478932 fonctions.
Quand au variables, pouvoir charger un tableau de localisation à la demande, par exemple, ,ou bien encore un fichier de configuration composée de variables, me semble également une chose qui peut avoir un intérêt, même si j'avoue que le concept me semble moins pertinent.
12 De jubianchi - 15/12/2010, 12:22
@mageekguy : je me suis peut être emporté un peu vite...
Effectivement dans certains cas ces mécanismes sont intéresants... mais pour l'autoloading de variable par exemple, si ce mécanisme est utilisé dans un projet, à chaque test sur une variable (isset, isnull, ...) on aura un appel a une fonction qui va devoir rechercher avec des règles plus ou moins compliquées, si cette variable peut être chargée dynamiquement. A mon sens cela allourdi pas mal le fonctionnement d'un script.
En plus j'imagine déja des implémentations "exotiques" que l'on va certainement rencontrer si ce mécanisme est validé, du genre :
function __autodefine($name, $type) {
}
Et ça, sa me fait vraiment peur...
13 De metagoto - 15/12/2010, 15:32
Je n'ai pas lu/suivi la mailing list à propos de __autodefine. Les remarques qui suivent sont donc "à chaud".
Je ne vois pas comment on s'y prend pour "autodefinir" des méthodes manquantes. Par exemple, __autodefine reçoit "PHP->im" en premier paramètre. Que fait-on avec ça?
Autoloader les fonctions (pas les méthodes), c'est effectivement un truc qui manque à l'heure actuelle. Autoloader des array ou des variables, ça me parait difficilement réalisable, parce que la "variable" est par hypothèse non définie, php n'est donc pas en mesure de connaitre son type précis (dans bien des cas).
Truc con: je suis dans __autodefine avec ces paramètres: ('piece', T_INCLUDE).
Qu'est-ce que je fais? Je fais un include... et on tombe sur des calls recursifs!
Du coup, je ne vois pas l'intéret d'autodefinir les include/require à part si on cherche à fortement compliquer les choses (ce qui peut être tout à fait louable).
PS: normalement (on ne sais jamais), le dernier Drupal est vachement "OOP".
14 De mageekguy - 16/12/2010, 14:20
@metagoto : En ce qui concerne les variables, le sujet a été évoqué, sans plus, sur internals@.