mageekblog - Mot-clé - Dmitry StogovLe blog personnel de Frédéric Hardy. Au menu, PHP, agilité, FreeBSD, cuisine et photographies.2021-12-02T08:20:54+01:00Frédéric Hardyurn:md5:26874ca5b8cd4cac8d08b0e68e64f63aDotclearEspace de noms et importations de classesurn:md5:0e4ba574ca7dcbc73503a7f18eebd7db2011-07-14T15:00:00+02:002012-06-22T15:55:32+02:00mageekguyPHPAliasDmitry StogovEspace de nomsImportationPHP<p>Il y a deux ou trois semaines, j'ai découvert un comportement étrange de <a href="http://www.php.net">PHP</a> lorsque j'utilisais <a href="http://fr2.php.net/manual/fr/language.namespaces.importing.php">l'importation d'espaces de noms</a> au sein de <a href="https://github.com/mageekguy/atoum">atoum</a>, mon framework de tests unitaires pour PHP 5.3, matérialisé par le message d'erreur suivant :</p>
<blockquote><pre><code>Fatal error: Cannot use ns\class2 as class2 because the name is already in use in /path/to/ns_ns1_ns2_class1.php on line X</code></pre></blockquote>
<p>D'après PHP, j'importais une classe via la syntaxe <code style="font-family: 'Courier New',Courier,monospace; font-size: 1.1em; color: rgb(102, 102, 102); font-weight: bold;">use ns\class2</code> dans l'un de mes fichiers alors que son nom était déjà utilisé par une autre classe dans un autre fichier.</p>
<p>Après une petite prise de tête, j'ai réussi à isoler le cas posant problème en quelques lignes de code, et j'en ai déduis que l'ordre de déclaration de mes classes avait une importance, puisque suivant la façon dont j'incluais mes fichiers, j'obtenais, ou pas, le message d'erreur.</p>
<p>Or, un espace de noms est censé avoir une portée limitée au fichier dans lequel il est déclaré, et en conséquence, il me semblait que l'ordre d'inclusion des fichiers n'avait pas d'importance et donc que ce message n'avait pas de sens.</p>
<p>J'ai donc rédigé <a href="https://bugs.php.net/bug.php?id=55068">un rapport de bug</a> à ce sujet, et j'ai attendu patiemment la réponse, pratiquement persuadé que j'avais débusqué un problème au sein de la gestion des espaces de nommage de <a href="http://www.php.net">PHP</a>.</p> <p>J'ai donc été très surpris lorsque Dmitry Stogov a fermé mon rapport de bug en me disant que ce n'était pas un bug, mais une fonctionnalité.</p>
<p>Connaissant un peu Dmitry, je me suis permis de lui demander des détails supplémentaires par courrier électronique, car je ne comprenais pas son explication.</p>
<p>Et quelques temps plus tard, j'ai reçu une réponse détaillée et très pédagogique, qui m'a permis de comprendre le problème.</p>
<p>J'ai donc décidé de vous en faire profiter, car à l'époque, le problème, que j'avais <a href="https://twitter.com/#%21/mageekguy/status/83457228094455808">exposé sur twitter</a>, avait suscité l'attention de certains.</p>
<p>En résumé, il n'est pas possible d'importer, par exemple, une classe dans un fichier sous le nom <code>foo</code> si une classe portant le nom <code>foo</code> est déjà définie au moment de l'importation.</p>
<p>Cela semble évident, mais dans mon cas, j'avais quelques difficultés à visualisé l'ordre dans lequel mes classes étaient définies.</p>
<p>Trés patient et pédagogue, <a href="http://php100.wordpress.com/">Dmitry</a> m'a alors commenté mon code afin que je comprenne ce qu'il se passait au niveau du Zend Engine lorsqu'il était exécuté :</p>
<blockquote><pre><code>require_once 'ns_class2.php';<br />// <-- nouvelle portée de fichier<br />namespace ns; // Déclaration de l'espace de nom "ns"<br />class class2 {} // Déclaration de la classe "ns/class2"<br />// Dans l'espace de noms "ns", "class2" est un alias de "ns\class2"<br />// Fin de la portée de fichier --><br /></code></pre></blockquote>
<blockquote><pre><code>require_once 'ns_ns1_ns2_class2.php';<br />// <-- nouvelle portée de fichier<br />namespace ns\ns1\ns2; // Déclaration de l'espace de nom "ns\ns1\ns2"<br />class class2 {} // Déclaration de la classe "ns\ns1\ns2\class2"<br />// Dans l'espace de noms "ns\ns1\ns2", "class2" est un alias de "ns\ns1\ns2\class2"<br />// Fin de la portée de fichier --></code></pre>
</blockquote>
<blockquote><pre><code>require_once 'ns_ns1_ns2_class1.php';<br />// <-- nouvelle portée de fichier<br />namespace ns\ns1\ns2; // Déclaration de l'espace de nom "ns\ns1\ns2"<br />// Dans l'espace de noms "ns\ns1\ns2", "class2" est un alias de "ns\ns1\ns2\class2"<br />use ns\class2; // Création de l'alias "class2" qui pointe vers "ns\class2" mais class2 est déjà un alias de ns\ns1\ns2\class2 => ERREUR !<br /></code></pre></blockquote>
<p>En résumé, l'ordre dans lequel sont inclus les classes est important dans ce contexte, et il faut donc éviter d'importer des classes en utilisant des noms qui sont susceptibles d'avoir été déclarés avant l'importation, quitte à utiliser le mécanisme d'alias via le mot-clef <code>as</code> pour éviter les collisions éventuelles.</p>
<p>Une autre solution peut être d'importer uniquement des espaces de noms, et non des classes, mais il faut dans ce cas être certain qu'aucune classe ne portera un jour le nom d'un espace de noms. </p>http://blog.mageekbox.net/?post/2011/07/14/Espace-de-noms-et-importations-de-classes#comment-formhttp://blog.mageekbox.net/?feed/atom/comments/273Mort de PHP6 + 190 joursurn:md5:b5bd8cbc480819a9d4ebf6ed57ea2f6d2010-09-20T18:30:00+02:002010-10-04T07:12:20+02:00mageekguyPHP XannotationsDmitry Stogovinternals@PHP XPierre Joyetrunkwindows<p>Je dois dire que cette dernière période de dix jours n'a pas été inintéressante, même si cela dépend du point de vue, comme vous allez pouvoir le constater dans la suite de ce billet.</p>
<p>En effet, la communauté des développeurs de <a href="http://www.php.net">PHP</a> a été très active, aussi bien au niveau de la liste de diffusion <a href="http://news.php.net/group.php?group=php.internals">internals@</a> qu'au niveau du <a href="http://svn.php.net/viewvc/php/php-src/trunk/">trunk</a> qui contient, en tout ou partie, ce qui deviendra la future version majeure du langage.</p>
<p>Les annotations, et plus particulièrement la <abbr title="Request For Comment">RFC</abbr> <a href="http://wiki.php.net/rfc/annotations">correspondante</a> et <a href="http://www.adoy.net/php/Annotations.diff">l'implémentation</a> qui en a été faite, ont été au centre d'un débat virulent et animé, et le <a href="http://svn.php.net/viewvc/php/php-src/trunk/">trunk</a> a subit une soixantaine de modifications.</p> <p>Je vais d'ailleurs commencer par ce dernier, car même si le nombre de modifications est important, ces dernières sont beaucoup moins passionnantes que la discussion au sujet des annotations qui a eu lieu sur la liste de diffusion.</p>
<p>Le support des liens symboliques pour la version pour Windows de <a href="http://www.php.net">PHP</a>, amorcé durant <a href="http://blog.mageekbox.net/?post/2010/09/09/Mort-de-PHP6-180-jours">la période précédente</a>, continue a être implémenté par <a href="http://blog.thepimp.net/">Pierre Joye</a>, avec notamment l'ajout de la gestion des liens symboliques au niveau de la directive <code><a href="http://php.net/manual/fr/ini.core.php">open_basedir</a></code>.</p>
<p>Le travail qu'il a réalisé sur ce point précis représente d'ailleurs quasiment la moitié des modifications effectuées sur le <a href="http://svn.php.net/viewvc/php/php-src/trunk/">trunk</a>, ce qui est loin d'être négligeable.</p>
<p>Un autre gros travai a été effectuée par <a href="http://news.php.net/php.internals/49610">Dmitry Stogov</a>, sur la gestion de la mémoire par le langage, qui est donc (encore une fois) moins gourmand à ce niveau, même si le gain dépend étroitement du contexte d'utilisation.</p>
<p>J'ai par exemple constaté, notamment lors de la mise en œuvre de la version du <a href="http://svn.php.net/viewvc/php/php-src/trunk/">trunk</a> en conjonction avec Atoum, mon framework de tests unitaires, une diminution très significative de la consommation de mémoire, de plus de 40% par rapport à PHP 5.3.3.</p>
<p>
De plus, les performances de la fonction <code><a href="http://fr.php.net/unserialize">unserialize()</a></code> ont de plus été améliorées et les bugs <a href="http://bugs.php.net?id=52802">#52802</a>,
<a href="http://bugs.php.net?id=51804">#51804</a>,
<a href="http://bugs.php.net?id=49215">#49215</a>,
<a href="http://bugs.php.net?id=52826">#52826</a>,
<a href="http://bugs.php.net?id=52772">#52772</a>,
<a href="http://bugs.php.net?id=48831">#48831</a>,
<a href="http://bugs.php.net?id=52827">#52827</a>,
<a href="http://bugs.php.net?id=52843">#52843</a>,
<a href="http://bugs.php.net?id=52849">#52849</a>,
<a href="http://bugs.php.net?id=49366">#49366</a> et
<a href="http://bugs.php.net?id=44331">#44331</a> ont été corrigés.
</p>
<p>Le reste des modifications correspond à des optimisations diverses au niveau du <a href="http://fr.wikipedia.org/wiki/Zend_Engine">Zend Engine</a>, et à du nettoyage du code, avec la suppression de fonctions ou de variables non utilisées ou bien encore de macros C qui sont devenues inutiles et la correction d'erreurs à la compilation.</p>
<p>La description des modifications effectuées sur le <a href="http://svn.php.net/viewvc/php/php-src/trunk/">trunk</a> de <a href="http://www.php.net/">PHP</a> étant maintenant complète, je vais maintenant parler des discussions qui ont eu sur <a href="http://news.php.net/group.php?group=php.internals">internals@</a>, la liste de diffusion des contributeurs au langage.</p>
<p>Je vais commencer par vous parler de celle relative à l'implémentation des annotations dans le langage, car c'est, et de loin, celle qui a monopoliser le plus la liste.</p>
<p>Pour rappel, tout a commencé <a href="http://news.php.net/php.internals/49507">le 25 août 2010</a> lorsque <a href="http://twitter.com/guilhermeblanco">Guilherme Blanco</a> et <a href="http://ca.linkedin.com/in/pierrickcharron">Pierrick Charron</a> ont proposé une implémentation technique de la <abbr title="Request For Comment">RFC</abbr> relative<a href="http://wiki.php.net/rfc/annotations"> au support des annotations</a> par <a href="http://www.php.net">PHP</a>, dont ils sont également les auteurs.</p>
<p>Depuis, le débat fait rage, entre ceux qui ne voient aucun intérêt aux annotations et/ou ne veulent pas compliquer le langage, ceux qui y voient un intérêt mais qui, au choix et non exclusivement, n'aiment pas la syntaxe proposée, n'aiment pas l'implémentation proposée, ou ignorent ce que sont les annotations, et ceux qui sont pour les annotations telles qu'elles sont proposées par les deux auteurs de la <a href="http://wiki.php.net/rfc/annotations"><abbr title="Request For Comment">RFC</abbr></a>.</p>
<p>Après des centaines de messages enflammés contenant des arguments plus ou moins recevables, un vote a finalement eu lieu, mais son résultat ne semble pas en faveur de l'implémentation proposée.</p>
<p>Ce résultat est cependant à prendre avec des pincettes.</p>
<p>En effet, le dépouillement a été effectué par mes soins, la communauté des contributeurs ne disposant d'aucun outil efficace pour ce genre de procédure, et j'ai très bien pu louper un vote, voir plusieurs, puisque chaque participant vote en envoyant un message sur la liste de diffusion avec une note pouvant être -1, 0 ou 1, en fonction du fait qu'il est contre, indifférent ou pour l'ajout de la fonctionnalité proposée.</p>
<p>Lors de mon dépouillement, il y avait donc 12 votants, dont 7 négatifs et 5 positifs, ce qui est à mon sens assez peu représentatif.</p>
<p>Pour autant, le débat est loin d'être clos et s'est encore compliquée, puisque deux débats transverses ont émergé.</p>
<p><a href="http://news.php.net/php.internals/49682">L'un</a> a pour but d'essayer de formaliser correctement le processus de soumission d'une nouvelle fonctionnalité, mais bizarrement, il n'est pas très actif.</p>
<p><a href="http://news.php.net/php.internals/49734">L'autre</a>, beaucoup plus actif, vise à supporter les annotations via le format <a href="http://en.wikipedia.org/wiki/PHPDoc#DocBlock">docblock</a>, même si son auteur s'en défend.</p>
<p>En effet, un support très partiel de ce format est déjà disponible dans <a href="http://www.php.net/">PHP</a> via <a href="http://fr.php.net/manual/fr/reflectionclass.getdoccomment.php">la réflection</a>.</p>
<p>Il semble en effet que ce soit le meilleur compromis actuellement, et en conséquence, la <a href="http://wiki.php.net/rfc/docblockparser"><abbr title="Request For Comment">RFC</abbr></a> relative à l'interprétation des commentaires au format <a href="http://en.wikipedia.org/wiki/PHPDoc#DocBlock">docblock</a> est au premier plan des discussions.</p>
<p>Bref, tout comme dans le cas du débat sur le contrôle du type des arguments, nous sommes loin d'en voir le bout, et il est difficile de dire si cette fonctionnalité sera un jour intégrée dans le langage et la forme que prendra cette intégration en l'état actuel des choses.</p>
<p>Cette rétrospective est maintenant terminée, vous pouvez reprendre une activité normale.</p>http://blog.mageekbox.net/?post/2010/09/20/Mort-de-PHP6-190-jours#comment-formhttp://blog.mageekbox.net/?feed/atom/comments/188