111 posts taggués « php »

Par Pascal MARTIN le lundi 4 novembre 2013 8 commentaires

Après septembre et ses 625 mails, voici mon dépilage d’internals@ pour le mois d’octobre 2013, qui est arrivé à un total de 562 messages.

Sous forme d’un graphique représentant le nombre de mails par mois sur les trois dernières années, on obtient (l’historique depuis 1998 est disponible ici) :

Nombres de mails sur internals@ ces trois dernières années


Depuis quelques mois, de nombreuses RFC ont été rédigées, visant PHP 5.6.

David Soria Parra, RM de PHP 5.4 et co-RM de PHP 5.5, a annoncé que, pour s’en tenir au planning prévu, PHP 5.6 devrait sortir en version stable dans 10 mois (c’est une coïncidence, mais cela permettrait à PHP 5.6 d’être inclue dans la prochaine Debian Stable, prévue pour dans 14 mois) — et que les dernières versions sorties avaient montré qu’il fallait environ 5 mois pour stabiliser une version et passer les phases alpha/bêta/RC.

Son mail indiquait qu’il était donc temps de commencer à réfléchir à l’organisation de la sortie de PHP 5.6, ainsi que de penser à trouver un RM pour cette version, afin qu’il ait déjà le temps d’apprendre sur PHP 5.5 — par la suite, plus de précisions sur le rôle du RM ont été données. Après quelques discussions, il est ressorti que les deux RM de PHP 5.6 seront Julien Pauli et Ferenc Kovacs.


En toute fin de mois dernier, Joe Watkins a annoncé avoir commencé à travailler sur la RFC: Nested Classes, qui pourrait par exemple être pratique pour les développeurs de bibliothèques ne souhaitant pas exposer certaines classes censées être utilisées uniquement en interne.

L’idée étant un peu complexe et demandant probablement plus de réflexion, Joe Watkins a fini par se demander si elle n’attendrait pas PHP 5.7, afin de ne pas arriver à une fonctionnalité pas assez réfléchie pour PHP 5.6.

En parallèle, il a annoncé l’ouverture des votes pour la RFC: Anonymous Classes — qui a finalement a été rejetée, avec 23 votes contre pour 9 votes pour.


Michael Wallner a noté que les variables super-globales $_GET et $_POST pouvaient être source de confusion, puisqu’elles peuvent être renseignées plus ou moins indépendamment de la méthode HTTP utilisée (Johannes Schlüter a par la suite fait remarquer que ces noms de variables correspondaient à ce qui est utilisé pour les formulaires HTML). Il a donc proposé de renommer $_GET en $_QUERY, et $_POST en $_FORM ; et, au passage, d’exposer les analyseurs de corps de requête à l’espace utilisateur, et de les déclencher indépendamment de la méthode HTTP utilisée.

Comme l’a rapidement fait remarquer Alexey Zakhlestin, ce renommage de variables casserait la quantité énorme de code les utilisant — mais les deux autres idées seraient intéressantes. Il n’était d’ailleurs pas le seul de cet avis.

Notons tout de même qu’exposer des parsers supplémentaires, si ce choix est retenu, doit être fait avec prudence : comme l’a rappelé Nikita Popov, cette idée a déjà mené à des vulnérabilités dans d’autres langages.


Joe Watkins a lancé un sujet de conversation, où il essayait d’attirer l’attention sur le fait que les assertions de PHP sont assez pauvres — d’ailleurs, est-ce que cela ne serait pas une raison pour laquelle elles sont si peu utilisées ?

Après quelques discussions tournant notamment autour de la levée d’erreur ou d’exceptions, Joe Watkins a annoncé avoir rédigé la RFC: Expectations1. Avec 50 mails dans la conversation, sans compter les échanges sur la discussion précédente, c’est visiblement le sujet qui a le plus attiré l’attention ce mois-ci.

Les premiers retours ont semblé être plutôt positifs, même si l’introduction d’un nouveau mot-clef expect pourrait causer des problèmes de compatibilité.

Suite à un mail où Derick Rethans faisait remarquer que la RFC n’apportait aucune indication quant à l’utilité de cette proposition par rapport à assert(), il a été répondu que la fonctionnalité aujourd’hui apportée par assert() était peu performante, et qu’elle ne pouvait pas être désactivée facilement en environnement de production, assert() étant une fonction et non une construction langage associée à un opcode. Joe Watkins a aussi apporté en réponse des précisions sur l’aspect erreur vs exception.

Les échanges s’étant fait plus rares en fin de mois, il y a des chances que cette RFC soit ouverte au vote sur les prochaines semaines.


Rowan Collins a proposé de marquer la fonction create_function() comme obsolète, considérant que le gros des usages (mais pas tous) pouvaient, depuis PHP 5.3, être remplacés par des utilisations de fonctions anonymes.

En effet, comme l’a souligné Nikita Popov, passer par create_function() est lent, consomme de la mémoire, et introduit parfois un risque en termes de sécurité.

Cela dit, Pierre Joye a répondu que de nombreuses fonctionnalités des versions récentes de PHP permettent d’écrire du code plus propre que celui que nous écrivions par le passé, mais que ce n’était pas une raison suffisante pour lever des notices partout — d’autant plus que create_function() est assez fortement utilisée, et fonctionne. Dans le même temps, supprimer cette fonction (ce qui est une suite logique, une fois qu’elle a été marquée comme obsolète ; mais ce serait pour PHP 5.7 ou plus, donc dans plusieurs années !) serait problématique pour des projets acceptant encore PHP 5.2 — Ryan McCue a ainsi noté que pour Wordpress, en cas de suppression de PHP, cette fonction devrait être ré-implémentée côté utilisateur (ce qui ne l’a pas empéché, sauf erreur d’interprétation de ma part, de trouver la proposition intéressante).


Nikita Popov a annoncé avoir rédigé la RFC: Exceptions in the engine, dont le but est de permettre la levée d’exceptions depuis le moteur de PHP, et de remplacer certaines Fatal Error par des levées d’exceptions.

Il a ensuite répondu à ceux qui s’inquiétaient des possibles impacts au niveau de la compatibilité entre versions de PHP, en soulignant que, quoi qu’il en soit, une Fatal Error ne correspondait déjà pas à un fonctionnement normal ni souhaité d’un programme. Autrement dit, le seul changement qui serait visible correspond à un cas où un script ne fonctionnait déjà pas.

Plusieurs ont indiqué trouver l’idée extrêmement intéressante, voulant même parfois aller plus loin que le remplacement de seulement quelques erreurs fatales — ce qui serait, pour le coup, un gros changement avec un impact massif en termes de compatibilité.

Dans le même temps, certains ont noté qu’il n’était peut-être pas urgent d’effectuer ce type de modification2. Le sujet d’une éventuelle version de PHP 6.x a donc recommencé à surgir : il permettrait de mettre en place, petit à petit, ce type de modifications potentiellement impactantes, tout en ne gelant pas l’arrivée de modifications plus mineures via des versions comme PHP 5.6 et 5.7.


Andrea Faulds a annoncé avoir rédigé la RFC: list() Reference Assignment, qui permettrait d’utiliser une syntaxe de ce type :

$array = [1, 2];
list($a, &$b) = $array;

A la place (comme raccourci, donc) de la syntaxe suivante :

$array = [1, 2];
$a = $array[0];
$b = &$array[1];


Cela aidera sans doute ceux d’entre nous qui travaillent sous Windows : Anatol Belski a annoncé que les builds pour Windows d’extensions PECL étaient maintenant référencés directement depuis les pages de chaque extension (par exemple, pour solr ou pour APC) — et ce pour une centaine d’extensions sur les environs 300 hébergées par PECL.

Benjamin Schneider a proposé d’ajouter une nouvelle exception, InvalidStateException, à l’extension SPL (Guilherme Blanco a répondu qu’elle pourrait être nommée IllegalStateException). Levi Morrison a fait remarquer que la partie exceptions de la SPL n’était pas des plus structurées, et qu’il pourrait être intéressant de mener une réflexion plus approfondie avant d’ajouter une nouvelle classe — il existe d’ailleurs la RFC: SPL Improvements sur le sujet depuis 2011, mais elle introduirait pas mal d’incompatibilités ; une seconde RFC, RFC: SPL Improvements: Exceptions se concentre, elle, sur les exceptions.

De son côté, Lior Kaplan a continué à poster régulièrement ses rapports sur l’état des Pull Requests faites sur le projet PHP.

Daniel Lowrey a quant à lui annoncé avoir rédigé la RFC: TLS Peer Verification. Il n’y a pas vraiment eu de retour autour de cette proposition ni des autres points qu’il évoquait dans son mail ; peut-être sur les prochaines semaines ?

La RFC: Extended keyword support dont j’avais parlé le mois dernier a été ouverte aux votes — et a été rejetée. Il est à noter que plusieurs votants ont expliqué pourquoi avoir voté non — ce qui est une bonne chose.

Yasuo Ohgaki a annoncé avoir rédigé la RFC: Make session_regenerate_id()’s delete_old_session parameter required gracefully, en vue d’améliorer la sécurité des sessions.

Andrea Faulds a implémenté les fonctions apache_request_headers() (aussi aliasée sous le nom plus générique getallheaders()) et apache_response_headers() pour le serveur web de test intégré à PHP. Même si ce serveur web n’est pas Apache, ces deux fonctions permettent de le rapprocher des autres SAPI.

Dmitry Stogov a proposé deux patchs éliminant des copies inutiles de variables dans array_merge() et func_get_args(), rendant par exemple la page d’accueil de Wordpress 2% à 4% plus rapide. Voici deux petites optimisations qui pourraient trouver leur place dès PHP 5.5 ! Dans la foulée, il a aussi proposé un patch qui éliminerait quelques appels au Garbage Collector.

Après le départ d’Anthony Ferrara il y a quelques semaines/mois et le retrait des RFC qu’il avait rédigé, Andrea Faulds a annoncé avoir réouvert la RFC: Constant Scalar Expressions. Peu de réaction pour l’instant, mais peut-être dans les prochaines semaines…


Oh, et pour finir, tant que j’y pense et en sortant un peu du sujet : j’ai profité de ce week-end de trois jours pour lancer une collecte de données, qui devrait me permettre de prochainement publier un article “Statistiques de versions de PHP”le dernier remontant à janvier, il date un peu, et une mise à jour ne peut que faire du bien !

Et pour finir avec un peu d’auto-publicité : si le sujet vous intéresse, vous pouvez demander à être prévenu lorsque je publierai le livre électronique Développer une Extension PHP sur lequel je travaille régulièrement.



internals@lists.php.net est la mailing-list des développeurs de PHP ; elle est utilisée pour discuter des prochaines évolutions du langage, ainsi que pour échanger autour de suggestions d’améliorations ou de rapports de bugs.
Elle est publique, et tout le monde peut s’y inscrire depuis la page Mailing Lists, ou consulter ses archives en HTTP depuis php.internals ou depuis le serveur de news news://news.php.net/php.internals.



  1. Au moment où je publie cet article, la page de la RFC: Expectations est vide. Mauvaise manipulation, bug, ou changement d’avis, ce sera probablement à voir d’ici le mois prochain… 

  2. je ne peux m’empécher de sourire, considérant qu’un des reproches souvent fait à PHP est que des erreurs sont levées là où il serait possible d’utiliser des exceptions… 

Par Pascal MARTIN le lundi 21 octobre 2013 8 commentaires

Depuis quelques années, j’ai occasionnellement l’occasion de discuter du sujet du développement d’extensions PHP avec des collègues ou d’autres développeurs (lors d’aperos, de conférences, …), et il ressort souvent de la discussion que le sujet est intéressant, que certains d’entre nous ont envie d’essayer, ne serait-ce que pour le plaisir et par curiosité, mais que l’idée semble effrayante et qu’il y a comme un manque de documentation.

En parallèle, je crois que la première fois où j’ai développé une extension était lors d’une demi-journée organisée par l’AFUP Paris en 2011, où le sujet avait été présenté par Julien Pauli et Patrick Allaert1, sous forme d’une rapide introduction théorique suivie par une après-midi de pratique — et j’avais trouvé ça plutôt sympa.

Depuis, je n’hésite plus à aller fouiller de temps en temps dans le code de PHP2, et je me suis rendu compte que, même si je n’avais pas réellement codé en C depuis une petite dizaine d’années3, j’arrivais globalement à comprendre ce qu’il se passe4… Et avec le temps qui passe, ça a de plus en plus titillé ma curiosité ^^


J’ai donc fini par m’y mettre de plus en plus, en commençant par le classique “Hello World!” et en avançant petit à petit, tout en me disant qu’il pourrait être intéressant de prendre quelques notes, et de les partager — ce qui me donne aussi une raison de fouiller plus que je n’en ai parfois besoin sur le coup, rendant l’exercice encore plus enrichissant pour moi.

Résultat, j’ai commencé à écrire ce qui est en train de devenir un livre électronique, en français, à propos du développement d’Extensions PHP : en l’état actuel, 10 chapitres sont rédigés (ils représentent 225+ pages, soit 50,000+ mots), et 5 chapitres supplémentaires sont prévus mais pas encore commencés.

Ce livre sera distribué (en PDF/EPUB/MOBI) par le biais du site Leanpub, et en suivant la logique du Manifesto correspondant5, je le publierai alors qu’il ne sera pas encore achevé, et le mettrai ensuite à jour au fur et à mesure de l’écriture des évolutions et chapitres suivants, et/ou des corrections éventuelles.


En attendant cette publication prochaine, vous pouvez dès maintenant signaler votre intérêt et demander à être prévenu lors de la publication du livre : Développer une Extension PHP.


Voici quelques informations sur les sujets couverts par les chapitres déjà rédigés, qui devraient vous permettre de faire vos premiers pas dans le développement d’extensions PHP :

  • Création d’une première extension : il s’agit du premier chapitre du livre, qui est reproduit intégralement dans l’aperçu disponible au téléchargement. J’y explique comment créer le squelette d’une première extension, quels fichiers sources sont requis, et quelles structures de données et déclarations sont nécessaires.
  • Environnement de développement : ce chapitre montre comment compiler une version de PHP orientée développement d’extensions et quelles sont les informations qu’elle nous apporte. J’en ai profité pour présenter comment configurer Eclipse CDT pour obtenir un environnement de développement avec débugger graphique.
  • Écrire une fonction : les fonctions sont au cœur de PHP et de ses extensions. Nous verrons ici, entre autres, comment recevoir des paramètres et retourner une valeur. Ce sujet est abordé au travers de deux chapitres, le second intégrant des concepts supplémentaires, comme la réception de zval en paramètres, les fonctions attendant un nombre d’arguments variable, ou encore le type-hinting.
  • zval : les variables de PHP : les variables de PHP sont représentées, en interne, par une structure nommée zval. Ce chapitre nous montrera comment en créer, les lire et les manipuler.
  • HashTable et tableaux : la structure HashTable est utilisée par PHP pour stocker un ensemble de données, comme un tableau. Elle est tellement importante pour PHP qu’elle est fréquemment utilisée en interne, et que de nombreuses fonctions permettent de la manipuler.
  • Configuration par fichier .ini : le fichier php.ini représente, pour PHP et pour ses extensions, le standard de configuration permettant aux utilisateurs d’influencer sur leur comportement. Ce chapitre présentera comment exploiter au mieux cette possibilité de paramètrage.
  • Tests automatisés : vous n’envisageriez pas de développer une extension sans tests automatisés ? Moi non plus !
  • Quelques points divers : ce chapitre regroupe quelques points intéressants, mais qui ne méritaient pas à un chapitre à eux seuls, comme la déclaration de variables super-globales, de constantes, ou la personnalisation de phpinfo(). Ce chapitre est lui aussi reproduit intégralement dans l’aperçu disponible au téléchargement.

J’ai prévu d’aborder d’autres sujets, pour lesquels je n’ai pas encore commencé la rédaction.
Je pense en particulier aux points suivants :

  • Classes et objets
  • Travailler avec les flux
  • Développer une extension PHP sous Windows
  • Les ressources
  • Gestion de la mémoire

Une fois le livre publié, il sera mis à jour au fur et à mesure de la rédaction, entre autres, de ces chapitres — l’ordre dans lequel ils figurent ici n’étant en rien indicatif de leur ordre de rédaction.

Pour vous donner une idée de la vitesse à laquelle j’écris : j’ai commencé à réfléchir à ce projet il y a plus d’un an, mais je n’ai commencé à écrire qu’en février 2013, ce qui représente en gros une moyenne d’un chapitre par mois. Cela dit, j’écris à une allure variable, puisque j’ai fait une quasi-pause de plusieurs mois à un moment, alors que j’ai écrit un chapitre en une semaine et deux week-ends à un autre moment ; et sur les 245 jours écoulés depuis la création du repository hébergeant ce projet, j’ai été actif 80 jours (soit 32.7% du temps).



  1. Pour les curieux, l’extension d’exemple utilisée pour cette demi-journée est disponible sur le github de Patrick : PHP_Extension_Workshop

  2. L’instance OpenGrok de PHP est extrêment pratique, lorsque l’on veut naviguer dans son code source pour essayer de comprendre pourquoi une fonctionnalité se comporte comme elle le fait ! 

  3. J’ai véritablement découvert la programmation alors que j’étais au Lycée, en codant pour TI-92+, pour laquelle il était possible de développer en C avec GCC ; par la suite, j’en ai fait un peu pendant mon DUT, j’ai basculé sur d’autres langages pendant ma licence et mon master (j’ai notamment de forts bons souvenirs de soirées / week-end passés à coder en Perl ^^), et je n’ai pas eu l’occasion d’y retoucher depuis que je bosse — dans le web, on ne fait pas du C tous les jours… 

  4. J’avoue généralement regarder comment sont implémentées des fonctions / classes, et ne pas encore m’être plongé dans le moteur de PHP en lui-même ; peut-être un jour prochain ;-) 

  5. Par rapport à ce manifesto, j’ai même probablement attendu trop longtemps avant de me préparer à la publication, puisque j’ai rédigé entre la moitié et les deux tiers de ce que je prévoyais ! Mais je souhaitais que ce livre soit exploitable dès sa publication, sans que mes lecteurs ne soient complètement bloqués par l’absence de chapitres clefs. 

Par Pascal MARTIN le mardi 1 octobre 2013 4 commentaires

Après août, second mois des vacances d’été, raisonablement calme avec 451 mails, voici mon dépilage d’internals@ pour le mois de septembre 2013, qui a vu plusieurs discussions animées, et a re-passé pour la première fois en six mois la barre des 500 mails, arrivant à un total de 625 mails.

Sous forme d’un graphique représentant le nombre de mails par mois sur les trois dernières années, on obtient (l’historique depuis 1998 est disponible ici) :

Nombres de mails sur internals@ ces trois dernières années


Johannes Schlüter a rédigé un mail où il a listé les différentes évolutions et versions que PHP a connu depuis PHP 5.2 en 2006 : cela commence à en faire une bonne petite liste, qui font de PHP un langage qui évolue vite depuis quelques années — surtout si on compare son évolution à celles de C, C++, ou JAVA.

Ces évolutions sont une très bonne chose pour la plupart d’entre nous, mais deux problèmes se posent, en termes de maintenance :

  • D’une part, les nouvelles versions de PHP ne sont adoptées que lentement,
  • Et là où pas mal d’attention est concentrée sur les évolutions, en face, les bugs s’empilent (aujourd’hui, il y a environ 4000 tickets ouverts).

En conséquence, il serait probablement profitable de ralentir un peu le rythme des évolutions pendant quelques mois, pour consacrer un peu plus d’énergie à la maintenance de l’existant — maintenance nécessaire pour assurer la viabilité de notre langage de prédilection !


Stas Malyshev a annoncé avoir mis à jour la RFC: Skipping optional parameters for functions, qui permettrait d’invoquer une fonction sans avoir à spécifier de valeur pour ses paramètres optionnels non situés en fin de liste d’arguments :

// Déclaration de fonction 
function create_query($where, $order_by, $join_type='INNER', 
    $execute = false, $report_errors = true) {
    // ...
}

// Appel sans passer les 3ème et 4ème paramètres,
// qui prendraient leur valeur par défaut, spécifiée
// lors de la déclaration de la fonction
create_query("deleted=0", "name", default, default, /*report_errors*/ true);

Une proposition serait de ne pas du tout spécifier de valeur, plutôt que de réutiliser le mot-clef default, mais cela pourrait nuire à la lisibilité.

Bien sûr, comme l’a fait remarquer Florin Patan (qui n’est pas le seul de cet avis), implémenter une fonctionnalité de paramètres nommés résoudrait aussi ce problème ;-)

Au bout de quelques jours, la discussion s’est essouflée, et n’a pas avancée depuis plus de trois semaines.


Dans la foulée, Nikita Popov a annoncé avoir commencé à travailler sur la RFC: Named Parameters.

Cette idée de paramètres nommés est assez fréquemment évoquée depuis pas mal de temps (c’est une syntaxe qui existe notamment en Python, si j’ai bonne mémoire), et les premiers retours ont clairement indiqués que l’idée semblait intéressante pour beaucoup d’entre nous.

Au niveau des réserves, certains ont noté que cela signifie que les noms de paramètres ne devraient plus être modifiés une fois une bibliothèque publiée, et qu’il ne faudrait pas que cela encourage les développeurs à mettre en place des fonctions prenant trop d’arguments.

Bien sûr, il faudrait s’assurer que cette nouvelle possibilité syntaxique n’a pas d’impact négatif au niveau des performances (à première vue, ça semble correct),

Les discussions ne sont pas terminées, la syntaxe elle-même n’étant pas encore définie, de même que les erreurs pouvant être levées ou même le périmètre fonctionnel précis souhaité — plusieurs éléments de réponse ont été apportés par Nikita Popov dans ce mail. En tout cas, je suis curieux de voir l’évolution de cette propositions sur les prochains semaines !


Joe Watkins a annoncé avoir rédigé la RFC: Anonymous Classes, qui introduit le même type de fonctionnalité que les fonctions anonymes arrivées en PHP 5.3, mais pour des classes.

En copiant-collant un exemple d’idée postée par Michael Wallner, la syntaxe pourrait ressembler à quelque chose de ce type :

$subject->attach(new class implements SplObserver {
    function update(SplSubject $s) {
        printf("Got update from: %s\n" $subject);
    }
);

Bien sûr, cette proposition a levé la question de l’utilité d’une telle possibilité, et des cas d’utilisation correspondant (cette possibilitée est fréquemment utilisée en JAVA, par exemple, où des objet anonymes implémentant une interface peuvent être utilisés comme callbacks). S’est aussi posée la question de la sérialisation/désérialisation d’un objet instance d’une classe non-nommée.

La RFC a été enrichie suite aux discussions, et des ajouts complémentaires comme l’imbrication de classes sont déjà évoqués (mais probablement sous forme d’autres RFC). Je suis curieux de voir l’évolution de ce sujet sur les prochains mois.

D’ailleurs, alors que le mois touchait à sa fin, Joe Watkins a annoncé avoir rédigé un premier brouillon pour la RFC: Nested Classes. Faute de temps, celle-ci n’a pas encore été réellement discutée ; mais là encore, nous verrons dans les prochaines semaines les réactions que le sujet ne va pas manquer de lever !


La RFC: Syntax for variadic functions dont je parlais le mois dernier a été soumise aux votes. Avec 36 votes pour et 1 vote contre, elle est passée !

PHP 5.6 devrait donc supporter la syntaxe suivante (exemple repris de la RFC) :

class MySQL implements DB {
    public function query($query, ...$params) {
        $stmt = $this->pdo->prepare($query);
        $stmt->execute($params);
        return $stmt;
    }
    // ...
}

Ici, la syntaxe ...$params indique que query() est une fonction variadique, et que tous les arguments suivant $query doivent être placés dans le tableau $params.


Bob Weinand a annoncé avoir développé un patch qui permettrait d’utiliser des mot-clefs comme identifiants1(noms de fonctions / classes, étiquettes, …) ; cela réduirait l’impact de la liste de mot-clefs réservés.

Les retours ont été plutôt positifs dans l’ensemble, nombreux développeurs souhaitant parfois utiliser une partie de ces mots-clefs (comme list, par exemple) ; et les tests effectués n’ont pas mis en évidence d’impact significatif sur les performances. Cela dit, comme l’a souligné Johannes Schlüter, PHP se retrouverait alors avec deux listes de mots-clefs, certains pouvant être utilisés à certains endroits et pas d’autres — ce qui risque de complexifier les choses pour les utilisateurs, par rapport à une unique liste de mots-clefs ne pouvant être employés nulle part.

La modification n’étant pas réellement mineure, et la discussion identifiant plusieurs points sur lesquels plus de réflexion semblait nécessaire, Pierre Joye a finalement proposé qu’une RFC soit rédigée à ce sujet — et donc, Bob Weinand a rédigé la RFC: Extended keyword support.


Gordon Oheim a rédigé la RFC: Automatic Property Initialization, où il proposait qu’une écriture du type suivante :

class Point 
{
    private $x, $y;

    public function __construct($x, $y)
    {
        $this->x = $x;
        $this->y = $y;
    }
}

Puisse être remplacée par une syntaxe alternative, plus courte :

class Point
{
    private $x, $y;

    public function __construct($this->x, $this->y);
}  

Il n’y a pour l’instant eu que peu de retours sur cette proposition, qui a semblé être appréciée, même si la syntaxe peut sembler surprenante — et qu’une autre solution serait d’implémenter la fonctionnalité d’accesseurs qui avait été discutée il y a quelques mois.


Plus ou moins suite au départ d’Anthony Ferrara au tout début du mois, Florin Patan a posté un mail intitulé “Wake up”, où il soulignait le fait que le développement de PHP n’est pas aussi ouvert d’esprit qu’il le pourrait.

Une des premières suggestions qui est remontée évoquait l’idée de passer de la mailing-list internals@ à un forum, qui, possiblement, faciliterait les échanges. Sans surprise, cette idée n’a initialement pas été fort bien accueillie par tout le monde (avec un logiciel de messagerie correct, une mailing-list est utilisable ; à condition que ses membres suivent l’étiquette qui va bien). D’un autre côté, un forum pourrait permettre, par un système de votes, de mettre en évidence les discussions intéressantes, tout en poussant vers le bas les échanges moins constructifs et en permettant d’ignorer plus facilement les posts hors-sujet.

Cela dit, Terence Copestake a peut-être cerné une partie du problème, lorsqu’il a souligné qu’il y avait un conflit entre ceux qui voulaient que PHP reste un langage simple et accessible, et ceux qui voulaient en faire un outil/environnement professionnel complet — les deux visions s’opposant, sans personne pour réellement trancher.

Peut-être faudrait-il aussi que, comme le disait Jordi Boggiano, chacun respire un grand coup avant de répondre à un point qui les a énervé…

En rebondissant sur ce qui s’était dit sur le sujet précédent, Andrea Faulds a lancé un autre sujet de discussion, à propos de cette idée de forum ; une solution mélant hiérarchie et système de votes pourrait d’après lui compléter internals@. Pour éviter de couper les conversations entre ceux utilisant un système et ceux restant sur l’autre, il faudrait une synchronisation entre les deux mécanismes, ou même que la solution de forum agisse comme une surcouche à internals@.


C’était en toute fin de mois dernier, donc je n’en n’ai pas parlé à ce moment là : Johannes Schlüter a fait remarquer que, en l’état, windows.php.net n’était pas des plus utiles (pas à jour, downloads ne passant pas par les mirroirs, …). Après avoir répondu à pas mal des questions posées, Pierre Joye a aussi annoncé que du travail était en cours sur la construction automatique pour Windows des extensions PECL. Un peu dans la même veine, PHP 5.2, qui a atteint son EOL il y a plusieurs années, a été retirée de la page de téléchargements de windows.php.net.

Nikita Popov a annoncé avoir terminé la rédaction de la RFC: Argument Unpacking, reprenant une idée qui existe, par exemple, en Python, Ruby, ou Javascript — et faisant assez logiquement le lien avec la RFC: Syntax for variadic functions, passée un peu plus tôt. Cette RFC est arrivée en fin de mois, et n’a vu que peu de discussions (ce qui est souvent bon signe) ; à suivre dans les prochaines semaines, donc.

Comme sur les mois précédents, Lior Kaplan a continué à poster régulièrement des mails résumant l’activité autour des Pull Requests faites sur PHP.

Suite aux discussions du mois dernier à propos de l’implémentation d’un nouveau serializer, Jakub Zelenka a mis à jour la RFC: Internal Serialize API.

La RFC: Change crypt() behavior w/o salt a été ouverte aux votes. La période de votes n’est pas terminée, mais il semblerait que les choses s’orientent vers la levée d’une notice dans le cas d’un appel à crypt() en omettant le paramètre $salt.



internals@lists.php.net est la mailing-list des développeurs de PHP ; elle est utilisée pour discuter des prochaines évolutions du langage, ainsi que pour échanger autour de suggestions d’améliorations ou de rapports de bugs.
Elle est publique, et tout le monde peut s’y inscrire depuis la page Mailing Lists, ou consulter ses archives en HTTP depuis php.internals ou depuis le serveur de news news://news.php.net/php.internals.



  1. Il semblerait que l’idée avait déjà été évoquée par Ralph Schindler en 2006. 

Par Pascal MARTIN le lundi 30 septembre 2013

Toutes les fin de mois1, l’antenne lyonnaise de l’AFUP organise un ApéroPHP ; je cite la description qu’en fait Adrien Gallou, qui s’en occupe depuis quelques mois :

Les apéros PHP sont ouverts à tous, quelque soit le niveau,
le but est de rencontrer d’autres développeurs PHP de la région lyonnaise,
de boire un verre ensemble, de discuter de tout et de rien,
en fonction des envies de tout le monde.

L’apéro du 25 septembre 2013 était un peu particulier, puisqu’il a réuni des développeurs PHP et des développeurs Python, un développeur de chacune des deux communautés présentant son langage aux développeurs de l’autre communauté.

Les slides que j’ai utilisés comme support pour présenter PHP aux développeurs Python sont disponibles en ligne2 : Présentation de PHP, pour des développeurs Python.

Les slides utilisés par Arthur Vuillard, qui a fait la présentation inverse, sont eux aussi disponibles : Python pour les dévs PHP.



  1. En théorie, les ApéroPHP lyonnais ont lieu le 29 de chaque mois. En pratique, la date varie un peu, mais c’est généralement vers la fin du mois. Rendez-vous sur aperophp.net, ou suivez l’AFUP Lyon sur Twitter : @AFUP_lyon

  2. Pour ceux qui n’ont pas pu assister à la présentation en live et voudraient plus d’informations que les slides en eux-même, j’ai noté plein de choses dans les notes du présentateur, accessibles via la touche [s]

Par Pascal MARTIN le lundi 2 septembre 2013

Après juillet qui a marqué un premier mois de vacances d’été très calme avec 330 mails, voici mon dépilage d’internals@ pour le mois d’août 2013, qui a vu quelques discussions plus animées, et remonte à 451 mails.

Sous forme d’un graphique représentant le nombre de mails par mois sur les trois dernières années, on obtient (l’historique depuis 1998 est disponible ici) :

Nombres de mails sur internals@ ces trois dernières années


Pour commencer : ça y est, PHP 5.5 semble vraiment avoir atteint son rythme de croisière, avec deux versions publiées ce mois-ci : PHP 5.5.2 et 5.5.3 — la norme étant aux environs d’une version par mois, sauf correctif de sécurité, ce qui a été le cas ici.

PHP 5.5 sortie et stabilisée, les discussions sur internals@ semblent repartir, avec plusieurs propositions — visant principalement ce qui est susceptible de devenir PHP 5.6, peut-être l’année prochaine.


Sean Cannella a rédigé la RFC: Constructor Argument Promotion, dont l’idée permettrait de raccourcir les constructeurs assignant leurs paramètres à des propriétés de l’objet en cours de construction.

Comme l’a fait remarquer Stas Malyshev, cette syntaxe ajouterait de la magie, susceptible de compliquer le debugging. Il n’était d’ailleurs pas le seul à estimer que supprimer quelques lignes de code PHP simple soit risqué, par rapport à la complexité apportée par la syntaxe. Cela dit, comme l’a indiqué Jordi Boggiano, si cela peut éviter plus que ces quelques lignes, ce serait autant de temps de gagné.

Suite à ces échanges, Matthieu Napoli a suggéré une autre syntaxe, qui serait plus intuitive, et a semblé rencontrer plus de succès.

La discussion n’a pas duré bien longtemps, et s’est rapidement essouflée ; nous verrons dans les prochains mois si le sujet revient sur le devant de la scène.


Yasuo Ohgaki a proposé de mettre en place un nouveau gestionnaire de sérialisation pour les sessions, qui ne souffrirait pas des limitations du composant utilisé actuellement (limitations historiquement dûe à register_globals, qui n’est désormais plus supporté) — en particulier, aujourd’hui, il n’est pas possible d’avoir une clef numérique comme entrée de session (par exemple, $_SESSION[123]).

Stas Malyshev a répondu qu’il ne voyait pas l’intérêt de casser la compatibilité au niveau de la gestion des sessions pour une limitation que peu d’utilisateurs rencontraient. Comme l’a alors fait remarquer Leigh, implémenter un nouveau gestionnaire est acceptable, mais il ne devrait probablement pas être activé par défaut, pour ne pas casser la compatibilité ascendante.

Finalement, une option php_serializer pourrait être ajoutée pour les sessions ; non-activée par défaut pour l’instant.


Anthony Ferrara a rédigé la RFC: Constant Scalar Expressions, qui permettrait à PHP d’accepter des expressions constantes, calculées à la compilation, là où seules des constantes sont aujourd’hui valides.

Comme noté par Pierre Joye, une expression est souvent plus facile à lire que son résultat (si on parle de secondes, 60*5 peut avoir plus de sens que 300 ; dans un contexte de flags par bits, 1<<7 peut aussi être plus compréhensible que 127).

Stas Malyshev a fait remarquer qu’il était dommage que cette proposition ne supporte pas l’utilisation de constantes dans l’expression. Mais mettre en place la gestion de constantes semble être plus difficile ; et serait donc à traiter dans un second temps.

La RFC n’est pas encore arrivée à l’étape de votes, mais les retours ont l’air plutôt positifs (du moins tant qu’on ne parle pas d’utiliser des constantes dans l’expression — et la RFC n’en parle pas). A voir comment les choses évolueront, mais ça me semble plutôt bien parti !


Terry Ellison a demandé quels systèmes d’exploitations et quelles SAPI PHP 5.6 devrait supporter — l’idée étant que moins d’OS/SAPI à supporter signifie moins de temps à passer en tests/maintenance/corrections sur des plate-formes peu utilisées (la discussion tournait autour d’éventuelles améliorations pour ext/opcache, mais la question est plus générale).

Comme l’a fait remarquer Johannes Schlüter1, sortir des extensions vers PECL est relativement facile ; mais ce type d’approche est plus difficile pour les SAPI, qui ne peuvent pas réellement vivre hors de l’arborescence de PHP.


Les discussions ont continuées autour de la RFC: Importing namespaced functions, qui avait été rédigée le mois dernier.

Dans l’ensemble, les retours ont été plutôt positifs ; notamment parce que cette idée permettrait de remplacer des fonctions internes, et parce qu’elle montre une volonté de continuer à améliorer les choses pour PHP côté non orienté objet. Quelques retours ont aussi été fait en vue de corriger certains bugs de l’implémentation proposée.

Suite aux discussions, cette RFC: Importing namespaced functions a été ouverte aux votes. Avec 16 votes “pour” et 4 votes “contre”, elle est passée !


Il y a quelques semaines, on a beaucoup entendu dire que “le support de JSON serait supprimé de PHP”, en raison d’un problème de licence. Bien sûr, les choses sont loin d’être aussi graves — et en fait, le sujet n’a que peu été abordé sur internals@ : le composant JSON “de base” n’est pas libre au sens qui va bien du terme ; un autre composant existe depuis quelques temps, actuellement dans PECL ; une discussion est en cours pour voir ce qui pourrait être fait pour remplacer le composant “de base” par ce composant “PECL” — cela passera probablement par une RFC, une analyse des éventuelles différences de comportements et éventuelles différences au niveau des performances. Ce composant pourrait peut-être être intégré pour PHP 5.6.

Effectivement, peu de temps après, Remi Collet a annoncé la RFC: Switch from json extension to jsonc.

Cette nouvelle implémentation semble plus lente pour le décodage de JSON que l’implémentation actuelle non-libre, et comme l’a souligné Zeev Suraski, une partie importante des utilisateurs de PHP risque d’avoir du mal à comprendre qu’une nouvelle implémentation plus lente ait été retenue, uniquement à cause d’un détail de licence — et ce d’autant plus que changer d’implémentation risque toujours d’introduire de nouveaux bugs.


Nikita Popov a rédigé la RFC: Syntax for variadic functions, qui permettrait à une fonction d’accepter un nombre variable de paramètres, sans avoir à passer par func_get_args().

Comme l’a souligné Lazare Inepologlou, cela rend le code plus explicite : en regardant la définition de la fonction, son prototype, on comprendre immédiatement qu’elle accepte un nombre variable d’arguments.

Cette proposition étant arrivée en toute fin de mois, elle n’a pas encore été débattue très activement ; mais les premiers retours ont l’air plutôt positifs. Je suis curieux de voir si les discussions se poursuivront le mois prochain, et comment cette RFC évoluera !

En complément, Nikita Popov a aussi proposé la RFC: Argument Unpacking.

Les retours sont allés un peu dans les deux sens, entre ceux qui trouvent la syntaxe peu lisible au premier abord, ceux qui accepteraient que cette nouvelle idée ne s’applique qu’au dernier paramètre d’une fonction (notamment du fait que les arguments sont passés/reçus, en PHP, par position), et ceux qui apprécieraient de pouvoir se passer de pas mal d’usages de call_user_func().

Après… Comme l’a laissé entendre Pierre Joye, il va peut-être être temps de reparler de paramètres nommés…


J’ai l’impression que le sujet n’est pas tout à fait nouveau ; mais, cette fois, les choses sont faites de manière un peu plus formelle : Anthony Ferrara a publié une version brouillon de la RFC: Function Autoloading, dont l’idée est de permettre l’autoloading de fonctions et constantes — et plus uniquement de classes/interfaces/traits.

Comme l’a rapidement fait remarquer Stas Malyshev, là où les classes vont bien avec le principe d’un autoloader (généralement un fichier par classe), c’est souvent moins vrai pour les fonctions. Cela dit, une approche avec un fichier de fonctions par espace de noms serait probablement tout à fait acceptable.

Toutefois, un mécanisme d’autoloading pour les fonctions éviterait le reccours à des astuces du genre “passer par des méthodes statiques pour bénéficier de l’autoloading via la classe” (Genre l’adorable classe Utils — ou équivalent — qu’on trouve dans pas mal de projets…). Cela permettrait aussi à l’approche fonctions de bénéficier d’un outil extrêmement pratique, aujourd’hui réservé à la seule approche classes.

Bien sûr, la discussion est passée par l’argument “il n’y a pas ça dans symfony ou Zend Framework” — mais en même temps, si la fonctionnalité n’existe pas, elle ne risque pas d’être utilisée ; et les frameworks les plus populaires ne représentent probablement pas non plus l’ensemble des développeurs utilisateurs de PHP.

Cette discussion n’ayant commencée qu’en toute fin de mois, elle n’est pas encore arrivée à sa conclusion ; la RFC elle-même n’est encore qu’en statut brouillon. Je suis curieux de voir comment elle évoluera sur les prochaines semaines, considérant que les avis divergent fortement quant à l’utilité d’une telle fonctionnalité.


Lior Kaplan a continué à envoyer toutes les semaines un rapport sur les pull-requests en cours / mergées / fermées sur github. Voir aussi ce mail et celui-là : les PR sont traitées de plus en plus rapidement, ce qui est plutôt bon signe !

Yasuo Ohgaki a créé la FR: #65501 uniqid(): More entropy parameter should be true by default. En complément, Nikita Popov a ajouté que uniqid() est nettement plus rapide si on lui passe true en second paramètre. Toutefois, cette modification impactant la longueur de la donnée retournée par la fonction, elle ne devrait pas être effectuée à la légère.

Michael Wallner a mergé un correctif qui permet d’uploader des fichiers de taille supérieure à 2GB.

Yasuo Ohgaki a travaillé sur la FR #17860: auto detect whether session changed : plutôt que d’écrire les données de session à la fin de chaque requête, une optimisation serait de ne les écrire que si elles ont été modifiées (et, dans le cas contraitre, de changer la date de dernière modification du fichier, en cas de données enregistrées en fichiers, pour ne pas casser le garbage collector de sessions — ce qui serait tout de même plus rapide que de ré-écrire l’ensemble des données pour rien). Voici un petit gain de performances pour (probablement) PHP 5.6 !

En parlant d’optimisations, Nikita Popov a appliqué un patch permettant d’éviter une copie de données pour les fonctions retournant un tableau autrement que par référence.

La fonction crypt() appelée avec un seul paramètre génére un hash très faible. Une RFC a été créée pour déterminer quelle serait la meilleure solution à mettre en place pour prévenir les utilisateurs et éviter ce type de cas.



internals@lists.php.net est la mailing-list des développeurs de PHP ; elle est utilisée pour discuter des prochaines évolutions du langage, ainsi que pour échanger autour de suggestions d’améliorations ou de rapports de bugs.
Elle est publique, et tout le monde peut s’y inscrire depuis la page Mailing Lists, ou consulter ses archives en HTTP depuis php.internals ou depuis le serveur de news news://news.php.net/php.internals.



  1. Note à moi-même : le commentaire sur les mauvaises performances avec TSRM est assez joli (un cache d’opcodes ne servirait pas à grand chose dans un environnement threadé, tellement les perfs sont déjà mauvaises). Voir aussi cette réponse qui parle de 20% de pertes de perfs. 

Par Pascal MARTIN le jeudi 1 août 2013 7 commentaires

Après une succession de mois, comme mai et juin, très calmes, voici mon dépilage d’internals@ pour le mois de juillet 2013, qui a été encore plus loin niveau calme, avec seulement 330 mails.

Sous forme d’un graphique représentant le nombre de mails par mois sur les trois dernières années, on obtient (l’historique depuis 1998 est disponible ici) :

Nombres de mails sur internals@ ces trois dernières années


C’était prévu depuis quelques temps : suite à la sortie de PHP 5.5.0, Johannes Schlüter a annoncé que PHP 5.3 a atteint sa Fin de Vie, et que PHP 5.3 ne recevrait plus que des correctifs de sécurité — et ce pour une durée de un an.

Il est donc plus que temps de passer à PHP 5.4, qui est stable depuis plus d’un an ; ou même, de monter directement à PHP 5.5, qui a été déclarée stable il y a un peu plus d’un mois.

En parallèle, PHP 5.5 semble commencer à suivre un cycle d’une version mineure par mois (comme le fait PHP 5.4 depuis un bon moment, et comme l’a aussi fait PHP 5.3) : PHP 5.5.1 a été publiée le 18 juillet.


Chris London a évoqué l’idée d’ajouter à l’instruction foreach() une syntaxe du type foreach ($array as $key => ) {}, qui pourrait servir lorsque l’on souhaite itérer seulement sur les clefs d’un tableau.

Ajouter un nouveau cas pour cette situation ne semblait pas nécessaire à Robin Speekenbrink, qui a proposé d’utiliser array_keys(). Mais comme l’a ensuite souligné Nikita Popov, c’est un cas où la fonctionnalité de Générateurs introduite en PHP 5.5 serait utile, évitant de charger en mémoire l’ensemble des clefs du tableau.


Lior Kaplan a fait une première passe sur les Pull Requests Github en attente, en vue de faire un peu de tri entre celles qui peuvent être mergées, celles qui ont des impacts importants et pourraient nécessiter une RFC, et celles pour lesquelles une intervention de l’auteur d’origine est souhaitée.

Différents types de problèmes semblent se poser, lorsqu’il s’agit de ces PR non-mergées :

  • Dans certains cas, ceux qui les ont soumises disparaissent,
  • Il arrive que des PR soient soumises sans test associé — et les développeurs existant n’auront pas forcément le temps d’écrire des tests pour une fonctionnalité qu’ils n’ont pas eux-même poussée (comme l’a noté Stas Malyshev, il est plus intéressant de passer du temps à merger des PR complètes que de travailler sur d’autres incomplètes),
  • Occasionnellement, les discussions sur une PR en viennent à stagner,
  • Et, malheureusement, il n’y a pas assez de développeurs de PHP suivant les PR — et étant à même de comprendre les patchs soumis en vue de les valider.

Lior Kaplan a depuis continué à rédiger ce type de rapports ; j’espère que cela permettra aux PR d’être plus rapidement prises en compte.


Chris London a fait remarquer qu’il était possible d’incrémenter des lettres, mais pas de les décrémenter ; il a donc proposé d’implémenter cette fonctionnalité — ou de lever un avertissement indiquant que ceci n’est pas possible. Effectivement, comme l’a noté Martin Amps, il pourrait être bon de clarifier comment fonctionnent les manipulations de chaînes avec les opérateurs arithmétiques.

Yasuo Ohgaki a indiqué que ces comportements sont documentés, et implémentés de la sorte depuis des années.

Cela dit, j’aurais assez tendance à être d’accord avec Dan Cryer qui demandait quelle utilité il pouvait y avoir à utiliser des opérateurs mathématiques avec des chaînes de caractères.


Les language constructs comme isset() ou echo ne sont pas callable. Daniel Lowrey a demandé à quel point ceci est profondément ancré dans le moteur de PHP, et s’il y avait des chances pour que cela change un jour.

A cette question, Johannes Schlüter a répondu que les constructions langage n’avaient pas nécessairement la même sémantique que les fonctions. Par exemple, pour isset(), le paramètre n’est pas passé par la pile de paramètres standard, mais directement comme opérande de l’opcode correspondant — c’est d’ailleurs un élément fondamental qui permet de ne pas lever de notice lorsque isset() est invoqué sur une variable inexistante.

Pour echo et print, le fait que ces constructions soient utilisables sans parenthèses (et soient utilisées ainsi absolument partout) fait à lui seul qu’il ne serait pas envisageable d’en faire des fonctions.


Yasuo Ohgaki a demandé en quoi une portion de code comme echo ++$a + $a++; pouvait mener à un résultat non-défini ; et a rapidement modifié la documentation pour supprimer l’avertissement correspondant.

Sara Golemon a par la suite rédigé une réponse expliquant plus précisément ce qui était indéfini et pourquoi ; d’après elle, et d’après d’autres, la modification de documentation devrait être annulée.

Finalement, Yasuo Ohgaki a annulé son commit sur la documentation, et même proposé d’améliorer celle-ci.


Je parlais le mois dernier de l’idée qu’avait évoquée Florin Patan d’ajouter à PHP la notion de retour typé. Sara Golemon a fait remarquer que ceci existait déjà dans HHVM, et que si c’était aussi implémenté dans PHP, il serait intéressant que les deux implémentations suivent la même logique, plutôt que de partir chacune dans leur direction.

Igor Wiedler a remis en avant le sujet de l’import de fonctions namespacées, pour lequel il avait rédigé la RFC: Importing namespaced functions il y a quelques mois de cela. Suite aux premiers retours, la RFC a été mise à jour pour ajouter le support de constantes namespacées.

En toute fin de mois, Julien Pauli a proposé d’ajouter une méthode \closure::isbindable(), permetant de déterminer si une closure données est ou non bindable.

Notons aussi que plusieurs sujets de discussion ont évoqué des travaux en cours, corrections de bugs et améliorations mineures — par exemple, sur PDO_DBLIB et les extensions PostgreSQL, ou sur l’extension AOP.


Nous voila sur les deux mois de congés d’été, et cela se sent sur internals@ : peu de discussions sont actives, et elles voient moins d’intervenants et d’échanges que ce que l’on peut usuellement constater le reste de l’année… Néanmoins, les idées continuent d’arriver, et les discussions ne s’arrêtent pas ;-)



internals@lists.php.net est la mailing-list des développeurs de PHP ; elle est utilisée pour discuter des prochaines évolutions du langage, ainsi que pour échanger autour de suggestions d’améliorations ou de rapports de bugs.
Elle est publique, et tout le monde peut s’y inscrire depuis la page Mailing Lists, ou consulter ses archives en HTTP depuis php.internals ou depuis le serveur de news news://news.php.net/php.internals.


Par Pascal MARTIN le lundi 29 juillet 2013

Toutes les fin de mois1, l’antenne lyonnaise de l’AFUP organise un ApéroPHP ; je cite la description qu’en fait Adrien Gallou, qui s’en occupe depuis quelques mois :

Les apéros PHP sont ouverts à tous, quelque soit le niveau,
le but est de rencontrer d’autres développeurs PHP de la région lyonnaise,
de boire un verre ensemble, de discuter de tout et de rien,
en fonction des envies de tout le monde.

Lors de l’Apéro du 24 juillet 2013, j’ai eu l’occasion de donner une rapide présentation, où j’ai parlé des nouveautés apportées par PHP 5.5, la dernière version stable de notre langage de prédilection, qui a été publiée fin juin.

Les slides que j’ai utilisés comme support sont disponibles en ligne2 : PHP 5.5 : slides de ma présentation à l’AperoPHP lyonnais du 24 juillet.


Et puisque j’ai eu plusieurs discussions à ce sujet après la présentation :

  • Je publie tous les mois, sur ce blog, une synthèse de la mailing-list internals@ — la mailing-list des développeurs de PHP ; les articles correspondant sont taggés @internals.
  • Les articles de mon blog sont bien sûr disponibles via un flux RSS ;-)



  1. En théorie, les ApéroPHP lyonnais ont lieu le 29 de chaque mois. En pratique, la date varie un peu, mais c’est généralement vers la fin du mois. Rendez-vous sur aperophp.net, ou suivez l’AFUP Lyon sur Twitter : @AFUP_lyon

  2. Pour ceux qui voudraient plus d’informations que les slides en eux-même, j’ai noté quelques points dans les notes du présentateur, accessibles via la touche s. Vous pouvez aussi vous reporter à la série d’articles que j’ai rédigée sur PHP 5.5 il y a quelques mois : j’y ai couvert, en détails, la plus grosse partie des nouveautés présentées lors de cet AperoPHP. 

Par Pascal MARTIN le mercredi 10 juillet 2013 1 commentaire

Après des mois d’avril et de mai très calmes, voici mon dépilage d’internals@ pour le mois de juin 2013, qui a lui aussi été calme, avec seulement 422 mails.

Sous forme d’un graphique représentant le nombre de mails par mois sur les trois dernières années, on obtient (l’historique depuis 1998 est disponible ici) :

Nombres de mails sur internals@ ces trois dernières années


Après l’annonce de la publication de la version RC3 le 6 juin, Julien Pauli a annoncé, le 20 juin, la sortie de PHP 5.5.0 !

En parallèle, et comme prévu depuis plusieurs mois, Johannes Schlüter a annoncé qu’il n’y aurait plus de nouveau développement sur la branche PHP 5.3 — et que seuls les problèmes de sécurité pourraient encore être traités. Il est donc temps de commencer à penser à migrer vers PHP 5.4 — ou même, vers PHP 5.5 !

Suite à la sortie de PHP 5.5, qui inclut ext/opcache, Julien Pauli a relancé un appel déjà effectué le mois précédent : il serait vraiment bon que cette fonctionnalité, qui est une des nouveautés de PHP 5.5 attendue depuis des années, soit documentée !


Fin mai, Anthony Ferrara avait lancé une discussion où il proposait qu’une passe de nettoyage soit effectuée dans le code de PHP, autour des types entiers et chaînes de caractères ; cela devrait entrainer beaucoup de changements dans le code de PHP, mais n’avoir que peu d’impact sur le comportement du moteur tel que les utilisateurs le voient. Comme l’a souligné Pierre Joye en réponse, cela fait longtemps que cette idée revient régulièrement, et il serait temps d’agir. Considérant la charge de travail, plusieurs intervenants ont proposé leur aide.

Cela dit, comme l’a rapidement fait remarquer Johannes Schlüter, ce type de modification demande beaucoup de travail (le moteur de PHP représente énormément de code, et il faut pas oublier les extensions), et il n’est pas rare que ce type de projet soit abandonné en cours de route. Et, presque un mois après, je n’ai pas le sentiment que les choses aient réellement avancées.


Joost Koehoorn a annoncé avoir rédigé la RFC: Support for anonymous catches : l’idée est de rendre optionnelle la variable dans le bloc catch d’une exception, voire même d’aller jusqu’à rendre celui-ci complètement anonyme, sans spécifier le type de l’exception attendue.

Dans l’ensemble, les retours ont souligné que ne pas avoir à introduire une variable parfois non utilisée pouvait être intéressant. Mais, en même temps, les modifications proposées pourraient rendre le code moins explicited’autant plus que même si la variable d’exception n’est pas nécessairement directement utilisée, elle peut apporter des informations utiles lors d’une phase de debug.

Après quelques jours de débats, je n’ai pas l’impression que les choses aient réellement avancées : ne pas devoir spécifier de variable pourrait être sympa en termes de syntaxe, mais sans plus ; et ne pas devoir spécifier de type d’exception ne semble pas si intéressant… Nous verrons dans les prochaines semaines comment le sujet évolue.


Florin Patan a évoqué l’idée d’ajouter à PHP une notion de retour typé.

Comme l’a rapidement souligné Sherif Ramadan, fixer le type de retour d’une fonction ne colle pas réellement à l’esprit souplement typé de PHP, ni au fait que nombre de fonctions de PHP peuvent retourner plusieurs types différents (par exemple, un entier en cas de succès, et un booléen false en cas d’erreur).

Cela dit, même si l’idée ne serait pas applicable à toutes les fonctions, elle pourrait permettre, dans certains cas, de produire du code plus concis — qui aiderait certains frameworks et applications fortement orientées-objet.

Je suis curieux de voir si cette proposition, qui semble avant tout viser à améliorer la qualité du code, ménera à la rédaction d’une RFC, et ce que celle-ci pourrait donner.


Christian Stoller a évoqué l’idée d’introduire une nouvelle syntaxe permettant à foreach d’itérer sur des tableaux à plusieurs dimensions, sans avoir à imbriquer plusieurs structures foreach ; en somme, au lieu de quelque chose de ce type :

foreach ($array as $key => $innerArray) {
    foreach ($innerArray as $innerKey => $value) {
        // ...
    }
}

il serait proposé d’écrire quelque chose ressemblant à cela :

foreach ($array as $key => $innerArray as $innerKey => $value) {
    // ...
}

Je ne sais pas pourquoi, mais je crois que j’aurais tendance à être assez d’accord avec Yahav Gindi Bar qui avait l’air de trouver cette syntaxe difficilement lisible — en particulier avec plus de niveaux d’imbrications. Ce sentiment est d’ailleurs partagé par d’autres.


En toute fin de mois, Anthony Ferrara a annoncé avoir rédigé la RFC: Structural Type Hinting — ça a été le plus gros sujet de discussion du mois, avec un total de 50 mails en 5 jours.

Quelques explications supplémentaires quant à l’utilité de cette proposition peuvent être trouvées dans ce mail. Une utilité serait, au niveau du type-hinting de paramètres de méthodes, de ne plus dépendre d’un nom d’interface, mais de l’API publiquement exposée — quelque soit l’objet l’exposant. La réponse de Ralph Schindler est intéressante, aussi, d’ailleurs.

Les réactions ont été variées, entre ceux qui ont l’air de trouver la proposition géniale, et ceux qui ont évoqué un risque plus grand de problème en cas de changement d’interface — celle-ci étant vérifiée à l’exécution, et plus à la compilation.

Au bout de quelques jours, la discussion a un peu dégénérée, mais je suis curieux de voir ce que cette proposition est susceptible de donner dans les prochains mois !


Dmitry Stogov a relevé qu’une optimisation apportée à strtr() il y a quelques mois avait un impact négatif vraiment perceptible dans nombre de cas réels — correspondant au pire cas de l’algorithme nouvellement mis en place.

Matteo Beccati a travaillé sur l’extension pdo_pgsql, pour lui ajouter le support de quelques fonctionnalités spécifiques à PostgreSQL.

Gernot Vormayr a rédigé la RFC: Apparmor change_hat functionality for php-fpm. Le sujet n’a pas suscité tellement de réactions (aucun commentaire, et seulement trois votes), mais il semblerait, vu les résultats du vote, que la fonctionnalité soit bien partie pour être inclue dans la prochaine version de PHP (PHP 5.x — peut-être PHP 5.6 donc).

Alors que la fin de vie de PHP 5.3 a été annoncée, le Bug #53437: Crash when using unserialized DatePeriod instance, qui entrainait un plantage, pourrait être corrigé pour PHP 5.3 et 5.4 (il avait déjà été corrigé pour PHP 5.5).

Cela sera particulièrement intéressant pour ceux qui souhaiteraient comprendre le fonctionnement du moteur de PHP et s’intéresser (et même, pourquoi pas, participer) au développement de PHP : Julien Pauli, Anthony Ferrara et Nikita Popov ont annoncé avoir commencé à travailler sur une documentation des composants internes du moteur : PHP Internals Book. Deux chapîtres sont pour l’instant disponibles : Classes and objects, et Hashtables.

Anthony Ferrara a travaillé sur la correction d’un plantage lors de la Garbage Collection dans certains cas un peu extrêmes — correction qui a au passage menée a une optimisation. Comme l’a souligné Rasmus Lerdorf, si une correction de bug mène en plus à un gain de performances, il peut être intéressant de continuer à fouiller !

Une peu dans la même logique, Anthony Ferrara a noté qu’il serait intéressant de désactiver le Garbage Collector lorsque le traitement d’un script PHP est en phase de finalisation : s’il s’exécute à ce moment là (plus précisément, pendant qu’une variable est en cours de suppression), il arrive que PHP plante. Cela dit, comme l’a souligné Stas Malyshev, avant de simplement désactiver le GC, il serait bon de comprendre pourquoi, réellement, ce plantage se produit — plutôt que de masquer le problème.

La RFC: Internal operator overloading and GMP improvements rédigée le mois dernier par Nikita Popov a été soumise aux votes. Ses deux composantes ont été acceptées (avec respectivement 14 et 15 votes pour, et 2 votes contre) ; il deviendra donc possible, à partir de PHP 5.6, de surcharger des opérateurs, pour les classes internes à PHP — et cette possibilité sera désormais exploitée pour l’extension GMP.

Sherif Ramadan a lancé une discussion où il a indiqué qu’il souhaitait permettre aux clefs d’un tableau d’être passées à la fonction de callback invoquée par array_filter(). Pour s’assurer de ne pas introduire de BC-break, une possibilité serait de plutôt ajouter une nouvelle fonction array_filter_keys(), ou, sinon, d’altérer le fonctionnement de array_filter() par le biais d’un troisième paramètre. Nous verrons probablement le résultat de la discussion dans les prochaines semaines.


Même si le mois n’a pas été un des plus agités sur internals@, j’ai l’impression que, maintenant que PHP 5.5 est sorti, de nouvelles (ou pas) idées recommencent à arriver sur le devant de la scène — en somme, l’effort de développement commencerait à se ré-orienter vers la prochaine version du langage ; probablement, PHP 5.6.



internals@lists.php.net est la mailing-list des développeurs de PHP ; elle est utilisée pour discuter des prochaines évolutions du langage, ainsi que pour échanger autour de suggestions d’améliorations ou de rapports de bugs.
Elle est publique, et tout le monde peut s’y inscrire depuis la page Mailing Lists, ou consulter ses archives en HTTP depuis php.internals ou depuis le serveur de news news://news.php.net/php.internals.


Par Pascal MARTIN le lundi 3 juin 2013 3 commentaires

Après un mois d’avril fort calme, voici mon dépilage d’internals@ pour le mois de mai 2013, qui l’a été tout autant, avec seulement 364 mails.

Sous forme d’un graphique représentant le nombre de mails par mois sur les trois dernières années, on obtient (l’historique depuis 1998 est disponible ici) :

Nombres de mails sur internals@ ces trois dernières années


La sortie de PHP 5.5 continue de se rapprocher : la version RC1 a été annoncée par Julien Pauli le 9 mai, suivie de la RC2 le 24 mai.

En parallèle, puisque PHP 5.5 intégre l’extension ext/opcache qui joue un rôle de cache d’opcodes, mais sans fournir de cache de données, Pierre Schmitz a demandé quelle était la solution à privilégier pour avoir à la fois un cache d’opcodes et un cache de données sur une installation PHP 5.5 — question particulièrement importante pour les packageurs de distributions Linux, dont les choix de configuration impacteront de nombreuses machines. Pour ce qui est du cache de données, plusieurs extensions existent, et aucune ne s’est encore réellement imposée.


Le sujet qui a vu le plus de messages s’échanger ce mois-ci (une soixantaine) a été lancé par Daniel Lowrey, qui regrette de prendre un E_WARNING à chaque fois qu’il utilise des fonctions de manipulation de dates sans avoir configuré la directive date.timezone. Cet avertissement est d’après lui (et il n’est pas le seul de cet avis) particulièrement ennuyeux lorsque PHP est invoqué en ligne de commandes — et potentiellement sans fichier php.ini.

En fait, ce qui est peut-être le plus surprenant est qu’un réglage par défaut entraine une levée d’avertissement — même si, comme l’a indiqué Derick Rethans, celui-ci est là pour signifier qu’il est nécessaire d’effectuer un choix intelligent, que PHP ne peut pas faire seul.

Une solution qui serait envisageable pour certains serait de prendre, par défaut, la timezone du système ; mais, comme l’a indiqué Pierre Joye, ce n’est pas aussi simple, et lorsque PHP essayait de détecter une timezone automatiquement, cette détection échouait souvent. Et comme l’a souligné Paul Reinheimer, il est souvent préférable d’avoir un avertissement plutôt qu’une valeur incorrecte.

Au final, au-delà du fait que PHP ne peut pas détecter une valeur par défaut, plusieurs intervenants estimaient qu’il pourrait être adapté de toujours prendre UTC comme valeur par défaut, mais ce n’est pas une solution pour nombre d’autres. Et après une soixantainte de mails, je n’ai pas le sentiment que les choses aient avancées, que ce soit dans un sens ou dans l’autre.


Thomas Anderson a remis sur le tapis l’idée d’une interface Comparable. Comme l’a fait remarquer Adam Harvey en réponse, l’idée n’est pas nouvelle, et il existe même une RFC — pour peu qu’il y ait des gens intéressés, elle pourrait être dépoussiérée, et re-proposée pour PHP 5.6.

Les premiers retours postés ont cette fois encore semblés plutôt opposés à cette proposition : elle pourrait introduire des cassages de compatibilité, et semble juste inutile à certains. En parallèle, d’autres ont pointé vers des exemples où une fonctionnalité de surcharge d’opérateurs pourrait être intéressante.

La discussion s’est rapidement tassée ; mais considérant que c’est un sujet relativement récurrent, je ne doute pas que nous le verrons revenir un jour ou l’autre. En attendant, certains voudront peut-être jeter un coup d’oeil à l’extension pecl/operator.


Nikita Popov a annoncé avoir rédigé la RFC: Internal operator overloading and GMP improvements, qui propose d’ajouter une surcharge d’opérateurs pour les classes internes à PHP, et implémente cette idée pour GMP.

Je parlais juste au-dessus de l’extension pecl/operator ; son auteur, Sara Golemon, est venue apporter quelques informations à ce sujet de discussion — et Dmitry Stogov a lui aussi indiqué qu’il pourrait être intéressant d’ajouter de nouveaux opcodes, pour gérer au mieux certains cas.

Les échanges qui ont eu lieu étaient tous centrés sur des aspects techniques, et aucun avis ni positif ni négatif n’a réellement été apporté — probablement du fait qu’il s’agit de permettre cette surcharge d’opérateurs uniquement pour des classes internes, et pas pour des classes déclarées depuis du code PHP. A voir si cette RFC ira jusqu’au vote dans les prochaines semaines.


Rouven Weßling a fait remarquer que la gestion de l’UTF-8 par PHP n’était pas vraiment parfaite, et a proposé d’ajouter de nouvelles fonctions à PHP, qu’il a pour l’instant développées sous forme d’une extension. Comme l’a souligné Martin Keckeis, le manque d’un bon support UTF-8 est un sujet récurrent ; auquel nous avons tendance à répondre en utilisant l’extension mbstring.

Nikita Popov a répondu qu’il existait déjà aujourd’hui une quantité non-négligeable de fonctions sachant manipuler de l’UTF-8, et qu’ajouter encore un ensemble supplémentaire de fonctions ne résoudrait pas le vrai problème. En effet, comme l’a noté Adam Harvey, après l’échec de PHP 6, il faudrait peut-être commencer à re-réfléchir à une approche plus globale de la gestion des encodages de caractères pour une prochaine version de PHP.


Richard Lynch a envoyé un mail à propos du fait qu’il faille, dans le constructeur d’une classe fille, appeler manuellement le constructeur de la classe mère ; mais que cet appel échouait et entrainait une Fatal Error dans le cas où la classe mère n’en définissait pas — ce qui, en particulier dans un contexte d’écriture/utilisation de bibliothèques, peut forcer à tester l’existence d’une méthode __construct() avant de l’appeler.

Stas Malyshev a rapidement répondu que, effectivement, il pourrait être intéressant d’améliorer quelque chose à ce niveau ; et qu’une première étape pourrait être la rédaction d’une RFC.

Etienne Kneuss a fait remarquer qu’avoir une classe de base explicite pour toutes les classes pourrait aider à résoudre ce type de problème ; cela pourrait aussi aider lorsque l’on souhaite type-hinter des objets.

La discussion a continué pendant quelques jours, sans qu’aucune décision ne soit pour l’instant prise ; je suis curieux de voir si elle continuera d’évoluer sur les prochaines semaines.


Suite à l’ouverture des sources de Zend Optimizer+ et à son intégration à PHP 5.5 sous le nom d’ext/opcache, il est intéressant de voir des posts comme celui de Terry Ellison, qui a demandé aux développeurs historiques de l’extension s’ils pouvaient jeter un coup d’oeil aux évolutions sur lesquelles il est en train de travailler.

Remi Collet a proposé de permettre à php-fpm de connaitre systemd ; il a ensuite expliqué que ceci permettrait à systemd de présenter des informations à propos du statut du service. La fonctionnalité semble appréciée, mais comme l’a rapidement fait remarquer David Soria Parra, Release Manager de PHP 5.5, cette version a atteint la phase de RC (et donc le feature-freeze correspondant), et cette nouveauté n’aurait pas dûe être intégrée à PHP 5.5.

Suite à une discussion entamée fin avril, Laruence a rérigé la RFC: Add an Second argument to callback of preg_replace_callback. La discussion n’a pas avancé bien loin, mais les retours n’étaient pas franchement positifs.

Bob Weinand a proposé d’ajouter une nouvelle méthode mysqli::bind_value(). Absolument aucun retour n’a été posté sur les plus de vingt jours qui ont suivis — l’idée ne semble pourtant pas mauvaise…

Sebastian Bergmann a fait remarquer que les messages d’erreurs et stacktraces des exceptions indiquent le numéro de ligne où l’objet Exception a été créé, et pas le numéro de la ligne où l’exception a été effectivement levée. Une discussion s’est ensuivie pour essayer de déterminer si ce comportement était le plus intéressant pour l’utilisateur, si utiliser le troisième paramètre du constructeur d’Exception était une bonne solution, s’il fallait ajouter un nouveau mot-clef rethrow au langage, … La discussion s’est un peu essoufflée en fin de mois, sans qu’aucune décision n’ait pour l’instant été prise.

Les votes se sont terminés sur la RFC: instance counter dont j’ai rapidement parlé le mois dernier. Conformément à ce que je pressentais, elle n’est pas passée, avec 14 votes contre, et un seul vote pour. Comme l’ont souligné plusieurs retours, ce type de fonctionnalité a plus sa place dans une extension comme Xdebug que dans le coeur de PHP.


Comme je disais il y a un mois, les choses sont relativement calmes sur internals@ en ce moment, et on ne voit en particulier pas d’ajout de nouvelle fonctionnalité ou de grosse évolution du langage. C’est probablement lié aux faits que PHP 5.5 est actuellement en phase de versions RC (qui signifie qu’il n’est plus possible d’y ajouter de fonctionnalité), et que PHP 5.6 est encore loin et pas encore entré en phase de développement actif — les efforts se concentrant sur les tests et la stabilisation de PHP 5.5.



internals@lists.php.net est la mailing-list des développeurs de PHP ; elle est utilisée pour discuter des prochaines évolutions du langage, ainsi que pour échanger autour de suggestions d’améliorations ou de rapports de bugs.
Elle est publique, et tout le monde peut s’y inscrire depuis la page Mailing Lists, ou consulter ses archives en HTTP depuis php.internals ou depuis le serveur de news news://news.php.net/php.internals.


Par Pascal MARTIN le lundi 6 mai 2013

Après un mois de mars relativement calme, voici mon dépilage d’internals@ pour le mois d’avril 2013, qui poursuit la tendance avec seulement 359 mails.

Sous forme d’un graphique représentant le nombre de mails par mois sur les trois dernières années, on obtient (l’historique depuis 1998 est disponible ici) :

Nombres de mails sur internals@ ces trois dernières années


La sortie de PHP 5.5 continue de se rapprocher : la version bêta3 a été publiée le 11 avril, et la bêta4 a suivi le 25 avril. Cette version bêta4 devrait être la dernière version bêta, la première version RC étant prévue pour le 9 mai.

Dmitry Stogov a travaillé sur des optimisations pour l’extension de cache d’opcodes ext/opcache qui sera inclue à PHP 5.5, et s’est demandé si ces optimisations avaient leur place dans PHP 5.5, ou s’il était plus prudent de les prévoir pour la version suivante de PHP. Une réponse apportée par Zeev Suraski est qu’il devrait être possible de mettre en place des optimisations ne travaillant que sur un seul fichier ; et que certaines idées ne mènent pas forcément à des résultats intéressants, le compilateur de PHP étant relativement rapide en lui-même. Pierre Joye, de son côté, a fait remarquer que, même si des optimisations simples pouvaient être appréciables, les versions RC de PHP 5.5 approchaient.

Comme l’a souligné Larry Garfield, une durée de compilation (compilation qui n’a lieu qu’une fois “de temps en temps”, avec un cache d’opcodes activé) un peu plus importante pour les scripts PHP est acceptable, à partir du moment où les gains à l’exécution ne sont pas négligeables.


Avec l’intégration de ext/opcache à PHP, Johannes Schlüter a fait remarquer qu’il y aurait probablement beaucoup d’utilisateurs qui essayeraient de charger cette extension avec extension= et non zend_extension= dans leurs fichiers de configuration. Le message d’erreur renvoyé lors de la tentative de chargement d’une Zend Extension avec extension= étant jusqu’à présent peu clair, pour éviter d’être submergés de demandes d’utilisateurs ne comprenant pas pourquoi ext/opcache refuse de se charger, il est proposé d’améliorer ce message — vu les nombreux retours positifs, le correctif a été intégré à PHP.

A la toute fin du mois de mars, Laruence a proposé d’ajouter une constante indiquant si PHP est compilé avec support des wrappers curl (qui sont totalement distincts de l’extension ext/curl !). Ces wrappers ayant toujours été considérés comme expérimentaux, la discussion a finalement donné lieu à la rédaction d’une RFC visant à leur suppression : RFC: Removal of curl-wrappers — et même si la décision a été un peu rapide pour rentrer dans la planning de sortie de PHP 5.5-bêta4, les wrappers curl seront supprimés pour PHP 5.5.


En tout début de mois, Sara Golemon a proposé la RFC: PHP Array API simplification : l’objectif est de fournir un fichier d’en-têtes .h permettant de simplifier les manipulations de tableaux PHP pour les développeurs d’extensions PHP (ce point ne concerne que les développeurs d’extensions, et absolument pas les utilisateurs de PHP). Comme l’a souligné Mike Willbanks, avec qui je ne peux être que d’accord, ce type de simplification est le bienvenu, en particulier pour les développeurs avec un background plus userland. La discussion n’a pas duré très longtemps et n’a pour l’instant pas mené à une inclusion de ce fichier d’en-têtes à PHP (peut-être pour une prochaine version ?), mais il peut dès maintenant être inclu manuellement par les développeurs d’extensions qui voudraient en tirer profit.

Un autre point qui peut intéresser les développeurs d’extensions PHP et/ou ceux qui aiment savoir comment ça marche : Julien Pauli a annoncé avoir rédigé un article expliquant comment PHP charge ses extensions, et les différents hooks appelés : internals:extensions. En parallèle, des améliorations sont en cours de développement autour du chargement d’extensions, et pourraient être mises en place pour PHP 5.6.


Laruence a proposé, comme décrit via le Bug #64554: var_export does not export absolute namespace for classname , d’ajouter un \ en début de noms de classes pour les sorties de var_export(), serialize(), et autres fonctions du même type. Certains ont noté que ceci semblait logique par rapport aux espaces de noms ajoutés avec PHP 5.3, alors que d’autres ont fait remarquer que cela casserait la compatibilité avec PHP <= 5.2 — et comme l’a souligné Rasmus Lerdorf, il n’est (malheureusement) pas rare de sérialiser des données avec une version de PHP, les stocker en base de données ou les envoyer via le réseau à une autre machine, et vouloir les lire avec une autre version de PHP. En conclusion, la documentation va être complétée, et le comportement de ces fonctions ne sera pas modifié.

Frank Liepert a rédigé la RFC: instance counter. Les quelques retours qui ont été postés sont assez négatifs : savoir combien d’instances d’une classe donnée existent ne semble pas vraiment intéressant ni utile. Les votes ont été ouverts sur cette RFC à la toute fin du mois — considérant le peu de discussions qu’il y a eu sur internals@ à ce sujet, je doute qu’elle passe.

Julien Pauli a proposé d’ajouter une option à phpinfo(), qui permettrait de récupérer la liste des options de configuration utilisées lors de la compilation de PHP (j’ai au passage découvert php-config --configure-options). Les retours ont été assez négatifs, puisque peu de développeurs voient l’utilité d’un mécanisme de ce type, et suggèrent de plutôt utiliser les capacités de reflection de PHP.

Julien Pauli a soumis une idée où le bloc catch d’une exception pourrait rendre le contrôle à son bloc try. Amaury Bouchard a ensuite fourni plus d’explications sur le pourquoi de cette idée. La discussion n’était pas terminée à la fin du mois, même si plusieurs semblaient penser qu’utiliser des constructions try/catch de cette manière n’était pas une bonne idée. Nous aurons peut-être l’occasion de voir le mois prochain si les choses ont évolué.

Igor Wiedler a annoncé avoir commencé à rédiger la RFC: Importing namespaced functions, et a ensuite posté quelques cas où cette idée lui semble utile. La discussion n’était pas terminée à la fin du mois, et se poursuivra peut-être en mai…


Depuis le premier article que j’ai posté dans cette série de dépilages d’internals@, en novembre 2012, je crois que c’est la première fois que j’ai aussi peu de choses à dire. C’est probablement lié aux faits que PHP 5.5 arrive tout juste à la fin de sa période de bêta, qui marquait la fin d’ajout de fonctionnalités pour cette version, et que PHP 5.6 est encore loin, et pas encore entré en phase de développement actif !



internals@lists.php.net est la mailing-list des développeurs de PHP ; elle est utilisée pour discuter des prochaines évolutions du langage, ainsi que pour échanger autour de suggestions d’améliorations ou de rapports de bugs.
Elle est publique, et tout le monde peut s’y inscrire depuis la page Mailing Lists, ou consulter ses archives en HTTP depuis php.internals ou depuis le serveur de news news://news.php.net/php.internals.