Jekyll2019-03-16T21:37:11+00:00http://php-internals.afup.org/feedPHP Internals en françaisSuivi des discussions de PHP Internals en FrançaisRFC: Scalar Type Declarations (v0.5)2015-03-30T08:30:09+00:002015-03-30T08:30:09+00:00http://php-internals.afup.org/2015/03/30/rfc-scalar-type-declarations-v0-5<p>L’idée d’introduire des <em>type-hints</em> scalaires pour les paramètres de fonctions et méthodes est revenue plusieurs fois sur le devant de la scène ces dernières années.</p>
<p><a href="https://wiki.php.net/rfc/scalar_type_hints">Une première RFC « Scalar Type Hints »</a> a récemment été jusqu’à la phase de votes (ceux-ci étant particulièrement serrés avec un nombre record de participants), mais a été retirée suite au départ de son auteur.</p>
<p>La demande de <em>type-hints</em> scalaires étant visiblement forte au niveau de la communauté (au vu des échanges sur twitter, du nombre de blog-posts sur le sujet, des réactions sur reddit, …), Anthony Ferrara a relancé l’idée quelques jours plus tard, avec une RFC forkée depuis celle d’Andrea :</p>
<ul>
<li>Scalar Type Declarations v0.5</li>
<li>URL : <a href="https://wiki.php.net/rfc/scalar_type_hints_v5">https://wiki.php.net/rfc/scalar_type_hints_v5</a></li>
</ul>
<p>Cette nouvelle version de la RFC introduisait quelques différences relativement mineures par rapport à la précédente version 0.3, qui était en cours de vote une semaine avant :</p>
<ul>
<li>L’instruction <code class="highlighter-rouge">declare()</code> doit désormais être la première du fichier.</li>
<li>Elle ne peut plus être utilisée en mode bloc ; seulement en mode fichier entier.</li>
<li>Les aliases <code class="highlighter-rouge">integer</code> et <code class="highlighter-rouge">boolean</code> ont été supprimés.</li>
<li>Et un entier est maintenant considéré comme valide pour le type-hint <code class="highlighter-rouge">float</code> ; y compris en mode strict.</li>
</ul>
<p>Une longue section <a href="https://wiki.php.net/rfc/scalar_type_hints_v5#discussion_points">« Discussion points »</a> a également été ajoutée, visant à répondre à de nombreuses questions habituelles sur le sujet et la proposition.</p>
<p>L’adoption de cette RFC demandait une majorité des 2/3 des voix. Les votes ouvert le 26 février ont été clôturés le 13 mars 2015. Comme pour la version précédente de cette proposition, <a href="http://news.php.net/php.internals/84658">nous avons exprimé un avis positif sur <code class="highlighter-rouge">internals@</code></a>.</p>
<p>Finalement, avec 108 votes « pour » et 48 votes « contre » (un tel nombre de votes, c’est un record !), cette RFC a été acceptée ! PHP 7.0 disposera donc de type-hints scalaires !</p>Pascal MARTINL’idée d’introduire des type-hints scalaires pour les paramètres de fonctions et méthodes est revenue plusieurs fois sur le devant de la scène ces dernières années.RFC: Generator Return Expressions2015-03-26T08:35:45+00:002015-03-26T08:35:45+00:00http://php-internals.afup.org/2015/03/26/rfc-generator-return-expressions<p>Voici une première RFC qui visait à élargir le périmètre fonctionnel des générateurs ajoutés avec PHP 5.5 :</p>
<ul>
<li>Nom : Generator Return Expressions</li>
<li>URL : <a href="https://wiki.php.net/rfc/generator-return-expressions">https://wiki.php.net/rfc/generator-return-expressions</a></li>
<li>Version cible : PHP 7</li>
</ul>
<p>Note : cette proposition conditionne la <a href="https://wiki.php.net/rfc/generator-delegation">RFC Generator Delegation</a>, qui a été rédigée quelques jours plus tard.</p>
<p>Cette RFC proposait de permettre aux fonctions générateur l’utilisation de <code class="highlighter-rouge">return</code> avec une valeur (ce qui provoque aujourd’hui une Fatal Error). Une méthode <code class="highlighter-rouge">Generator::getReturn()</code> serait alors ajoutée pour permettre l’obtention de cette valeur de retour. Elle ne pourrait bien sûr être appelée qu’une fois la fonction génératrice terminée.</p>
<p>En somme, cela permettrait d’avoir une vraie valeur de retour explicite pour les générateurs, plutôt que de considérer que la dernière valeur <em>yieldée</em> joue ce rôle.</p>
<p>Les votes ont été ouvert le 09 mars pour être clôturés le 16 Mars 2015. Nous avons <a href="http://news.php.net/php.internals/84998">exprimé un avis positif sur <code class="highlighter-rouge">internals@</code></a>.<br />
Et cette RFC a été acceptée à l’unanimité (33 votes « pour » et 0 vote « contre »).</p>Pascal MARTINVoici une première RFC qui visait à élargir le périmètre fonctionnel des générateurs ajoutés avec PHP 5.5 :RFC: Make empty() a Variadic2015-03-25T08:30:23+00:002015-03-25T08:30:23+00:00http://php-internals.afup.org/2015/03/25/rfc-make-empty-a-variadic<p>Voici une courte RFC autour de la construction <code class="highlighter-rouge">empty()</code> :</p>
<ul>
<li>Nom : Make <code class="highlighter-rouge">empty()</code> a Variadic</li>
<li>URL : <a href="https://wiki.php.net/rfc/variadic_empty">https://wiki.php.net/rfc/variadic_empty</a></li>
<li>Version cible : PHP 7</li>
</ul>
<p>Cette RFC partait de l’idée qu’il est commun de vouloir utiliser <code class="highlighter-rouge">empty()</code> sur plusieurs variables, en vue de déterminer si l’une d’entre elles est vide ou si aucune ne l’est ; ce qui passe actuellement par une portion de code de ce type :</p>
<figure class="highlight"><pre><code class="language-php" data-lang="php"> <span class="k">if</span> <span class="p">(</span><span class="k">empty</span><span class="p">(</span><span class="nv">$a</span><span class="p">)</span> <span class="o">||</span> <span class="k">empty</span><span class="p">(</span><span class="nv">$b</span><span class="p">)</span> <span class="o">||</span> <span class="k">empty</span><span class="p">(</span><span class="nv">$c</span><span class="p">))</span> <span class="p">{</span>
<span class="c1">// Une des variable est vide
</span> <span class="p">}</span>
<span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="k">empty</span><span class="p">(</span><span class="nv">$a</span><span class="p">)</span> <span class="o">&&</span> <span class="o">!</span><span class="k">empty</span><span class="p">(</span><span class="nv">$b</span><span class="p">)</span> <span class="o">&&</span> <span class="o">!</span><span class="k">empty</span><span class="p">(</span><span class="nv">$c</span><span class="p">))</span> <span class="p">{</span>
<span class="c1">// Aucune variable vide
</span> <span class="p">}</span></code></pre></figure>
<p>Pour simplifier l’écriture de ce type de test, cette RFC proposait de rendre <code class="highlighter-rouge">empty()</code> variadique (comme l’est déjà <code class="highlighter-rouge">isset()</code>), ce qui permettrait d’utiliser l’écriture suivante :</p>
<figure class="highlight"><pre><code class="language-php" data-lang="php"> <span class="k">if</span> <span class="p">(</span><span class="k">empty</span><span class="p">(</span><span class="nv">$a</span><span class="p">,</span> <span class="nv">$b</span><span class="p">,</span> <span class="nv">$c</span><span class="p">))</span> <span class="p">{</span>
<span class="c1">// Une des variable est vide
</span> <span class="p">}</span>
<span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="k">empty</span><span class="p">(</span><span class="nv">$a</span><span class="p">,</span> <span class="nv">$b</span><span class="p">,</span> <span class="nv">$c</span><span class="p">))</span> <span class="p">{</span>
<span class="c1">// Aucune variable vide
</span> <span class="p">}</span></code></pre></figure>
<p>Passer plusieurs expressions à <code class="highlighter-rouge">empty()</code> reviendrait à effectuer un OR entre <code class="highlighter-rouge">empty()</code> de chaque expression.</p>
<p>Les votes ont été ouverts le 7 mars 2015 pour être clôturés le 21 mars. Considérant que cette proposition apporterait un fort risque de confusion (est-ce qu’on vérifie qu’<em>au moins une</em> donnée est <em>vide</em> ? Ou est-ce qu’on vérifie que <em>toutes</em> les données sont <em>vides</em> ?), nous avons exprimé <a href="http://news.php.net/php.internals/85347">un avis négatif sur <code class="highlighter-rouge">internals@</code></a>.</p>
<p>Une majorité des 2/3 était requise pour l’adoption de cette RFC et elle a été rejetée, avec 26 votes « pour » et 26 votes « contre ».</p>Pascal MARTINVoici une courte RFC autour de la construction empty() :RFC: Context Sensitive Lexer2015-03-24T08:30:58+00:002015-03-24T08:30:58+00:00http://php-internals.afup.org/2015/03/24/rfc-context-sensitive-lexer<p>La <a href="https://wiki.php.net/rfc/context_sensitive_lexer">RFC: Context Sensitive Lexer</a> partait du constat qu’il existe actuellement <a href="http://php.net/manual/fr/reserved.keywords.php">64 mots clefs réservés</a> par PHP et que certains d’entre eux seraient très utiles en tant que noms de méthodes, pour définir des API claires côté utilisateur.</p>
<p>Elle proposait donc de modifier l’analyse du code PHP afin de disposer d’une analyse lexicale sensible au contexte, permettant l’utilisation de mots clefs ; en se limitant pour l’instant au périmètre de la programmation objet :</p>
<figure class="highlight"><pre><code class="language-php" data-lang="php"> <span class="c1">// Le code suivant devient possible:
</span> <span class="k">interface</span> <span class="nx">Collection</span>
<span class="p">{</span>
<span class="k">public</span> <span class="k">function</span> <span class="nf">forEach</span><span class="p">(</span><span class="nx">callable</span> <span class="nv">$callback</span><span class="p">);</span>
<span class="k">public</span> <span class="k">function</span> <span class="nf">list</span><span class="p">();</span>
<span class="p">}</span>
<span class="c1">// Mais pas le suivant:
</span> <span class="k">function</span> <span class="nf">list</span><span class="p">()</span> <span class="p">{</span><span class="cm">/* */</span><span class="p">}</span></code></pre></figure>
<p>De plus, cette RFC permettrait également de limiter les problèmes de rétro-compatibilité à l’avenir, lorsque PHP réservera de nouveaux mots clefs.</p>
<p>Considérant que pouvoir utiliser des mots-clefs comme noms de classes ou de méthodes était intéressant, nous avons (à l’unanimité !) <a href="http://news.php.net/php.internals/84734">posté en ce sens sur internals@</a>.<br />
Cette RFC a été acceptée pour PHP 7.0, avec 36 votes « pour » et 12 votes « contre ».</p>
<p> </p>
<p> </p>GuillaumeLa RFC: Context Sensitive Lexer partait du constat qu’il existe actuellement 64 mots clefs réservés par PHP et que certains d’entre eux seraient très utiles en tant que noms de méthodes, pour définir des API claires côté utilisateur.RFC : Improve array to string conversion2015-03-16T08:30:26+00:002015-03-16T08:30:26+00:00http://php-internals.afup.org/2015/03/16/rfc-improve-array-to-string-conversion<p>Voici une RFC qui tourne autour de la conversion de tableaux (<code class="highlighter-rouge">array</code>) en chaînes (<code class="highlighter-rouge">string</code>) : Improve array to string conversion</p>
<ul>
<li>URL : <a href="https://wiki.php.net/rfc/array-to-string">https://wiki.php.net/rfc/array-to-string</a></li>
<li>Version cible : PHP 7</li>
</ul>
<p>Cette RFC partait du constat que, aujourd’hui, convertir un <code class="highlighter-rouge">array</code> vers une <code class="highlighter-rouge">string</code> entraîne la levée d’une <code class="highlighter-rouge">E_NOTICE</code> et donne « <code class="highlighter-rouge">Array</code> » comme résultat… Autrement dit, une chaîne peu utile et seulement une _semi-_erreur.</p>
<p>Elle proposait au départ deux alternatives (opposées) visant à éliminer ce comportement problématique :</p>
<ul>
<li>Interdire totalement la conversion <code class="highlighter-rouge">array</code> → <code class="highlighter-rouge">string</code> en levant une « <code class="highlighter-rouge">catchable fatal error</code>« , comme c’est déjà le cas pour la conversion <code class="highlighter-rouge">object</code> → <code class="highlighter-rouge">string</code> pour les classes n’ayant pas de méthode <code class="highlighter-rouge">__toString()</code>.</li>
<li>Supporter réellement la conversion <code class="highlighter-rouge">array</code> → <code class="highlighter-rouge">string</code>, en déterminant et implémentant un algorithme réalisant la conversion.</li>
</ul>
<p>Après discussions sur <code class="highlighter-rouge">internals@</code>, la seconde option a été supprimée avant l’ouverture des votes, qui n’ont donc porté que sur la première.</p>
<p>Considérant que la conversion <code class="highlighter-rouge">array</code> → <code class="highlighter-rouge">string</code> n’était que rarement voulue et correspondait quasiment toujours à des cas de bugs, <a href="http://news.php.net/php.internals/84363">nous avons indiqué sur <code class="highlighter-rouge">internals@</code></a> que nous étions en faveur de cette proposition.<br />
La RFC a finalement été acceptée, avec 34 votes « pour » et 10 votes « contre ».</p>
<p> </p>
<p> </p>Pascal MARTINVoici une RFC qui tourne autour de la conversion de tableaux (array) en chaînes (string) : Improve array to string conversionRFC: Exceptions in the engine2015-03-12T08:46:35+00:002015-03-12T08:46:35+00:00http://php-internals.afup.org/2015/03/12/rfc-exceptions-in-the-engine<p>La <a href="https://wiki.php.net/rfc/engine_exceptions_for_php7">RFC: Exceptions in the engine</a> visait à généraliser l’utilisation d’exceptions dans le moteur PHP ainsi qu’à transformer en exceptions la plupart des erreurs fatales, ce afin de laisser aux applications la possibilité de contrôler ces erreurs.</p>
<p>Cette RFC introduisait pour cela deux nouveaux types d’exceptions :</p>
<ul>
<li><code class="highlighter-rouge">EngineException</code> : type d’exception générique générée par le moteur PHP</li>
<li><code class="highlighter-rouge">ParseException</code> : exception générée lorsque le code PHP ne peut être traité</li>
</ul>
<p>À cela s’ajoute une classe de base, abstraite, <code class="highlighter-rouge">BaseException</code>, qui viendrait se mettre en place dans la hiérarchie des exceptions comme suit :</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>BaseException (abstract)
+- EngineException
+- ParseException
+- Exception
+- ErrorException
+- RuntimeException
+- ...
+- ...
</code></pre></div></div>
<p>Les blocs attrapant les exceptions de type <code class="highlighter-rouge">Exception</code> n’attraperaient pas ces nouvelles exceptions, ne générant ainsi aucun effet de bord côté utilisateur.</p>
<p>Il est ressorti de nos échanges que nous étions en très large majorité en faveur de cette RFC et avons donc <a href="http://news.php.net/php.internals/84416">posté en ce sens sur internals@</a>.</p>
<p>Avec 60 voix pour et seulement 2 contre, cette RFC a été accepté et sera mise en place dans la version 7 de PHP.</p>GuillaumeLa RFC: Exceptions in the engine visait à généraliser l’utilisation d’exceptions dans le moteur PHP ainsi qu’à transformer en exceptions la plupart des erreurs fatales, ce afin de laisser aux applications la possibilité de contrôler ces erreurs.RFC: Remove PHP 4 Constructors2015-03-11T08:30:52+00:002015-03-11T08:30:52+00:00http://php-internals.afup.org/2015/03/11/rfc-remove-php-4-constructors<p>La <a href="https://wiki.php.net/rfc/remove_php4_constructors">RFC: Remove PHP 4 Constructors</a>, comme son nom l’indique, visait à supprimer les constructeurs introduits dans la version 4 de PHP, où la méthode de construction des objets était appelée comme la classe elle-même :</p>
<figure class="highlight"><pre><code class="language-php" data-lang="php"> <span class="k">class</span> <span class="nc">Filter</span>
<span class="p">{</span>
<span class="c1">// Constructor as introduced in PHP 4
</span> <span class="k">function</span> <span class="nf">filter</span><span class="p">()</span> <span class="p">{}</span>
<span class="p">}</span></code></pre></figure>
<p>Ce comportement, qui induit souvent en erreur les développeurs, est depuis longtemps vu par beaucoup comme indésirable. Néanmoins, sa suppression visant (initialement) la version 7 de PHP fut génératrice d’interrogations, notamment à cause de son utilisation récurrente dans les extensions PEAR ou même sur WordPress.</p>
<p>Ce sujet a également animé les débats sur <code class="highlighter-rouge">internals@</code> et la RFC a évolué pour passer en deux phases :</p>
<ul>
<li>PHP 7 : les anciens constructeurs génèreront un avertissement de type <code class="highlighter-rouge">E_DEPRECATED</code></li>
<li>PHP 8 : suppression des anciens constructeurs qui deviendront alors de simples méthodes.</li>
</ul>
<p>Suite à cette mise à jour, les derniers doutes furent levés et nous avons majoritairement approuvé cette RFC, <a href="http://news.php.net/php.internals/84361">postant dans ce sens sur <code class="highlighter-rouge">internals@</code></a>.</p>
<p>Avec 49 voix pour et seulement 4 contre, la dernière version de la RFC a été acceptée, devenant la toute première RFC validée ayant comme version cible PHP 8 !</p>
<p> </p>GuillaumeLa RFC: Remove PHP 4 Constructors, comme son nom l’indique, visait à supprimer les constructeurs introduits dans la version 4 de PHP, où la méthode de construction des objets était appelée comme la classe elle-même :RFC: Expectations2015-03-10T08:30:32+00:002015-03-10T08:30:32+00:00http://php-internals.afup.org/2015/03/10/rfc-expectations<p>Voici une RFC destinée à servir principalement en environnements de développement :</p>
<ul>
<li>Nom : Expectations</li>
<li>URL : <a href="https://wiki.php.net/rfc/expectations">https://wiki.php.net/rfc/expectations</a></li>
<li>Version cible : PHP 7</li>
</ul>
<p>L’idée derrière cette RFC, basée sur la fonction <code class="highlighter-rouge">assert()</code>, est de permettre l’exécution de code de débogage, en développement uniquement. Cela permettrait à la fois d’identifier des problèmes (encore une fois, en environnements de développement) et de documenter le code. Plusieurs exemples illustrant les différents cas d’usage sont donnés dans la RFC.</p>
<p>En cas d’échec, la condition spécifiée en premier paramètre de <code class="highlighter-rouge">assert()</code> n’étant pas vraie, une exception de type <code class="highlighter-rouge">AssertException</code> (soit spécifiée en second paramètre, soit générée automatiquement) sera levée — passer par une exception plutôt qu’une erreur permettant d’obtenir plus facilement une stacktrace.</p>
<p>L’activation ou non des assertions serait paramétrée par le biais d’une directive <code class="highlighter-rouge">.ini</code> nommée <code class="highlighter-rouge">zend.assertions</code>, qui pourrait valoir :</p>
<ul>
<li><code class="highlighter-rouge">1</code> : pour générer et exécuter le code correspondant aux assertions : c’est la valeur qui sera généralement utilisée en environnement de développement</li>
<li><code class="highlighter-rouge">0</code> : pour générer le code mais ne pas l’exécuter</li>
<li><code class="highlighter-rouge">-1</code> : pour ne pas du tout générer le code de l’assertion (coût nul, à utiliser en production)</li>
</ul>
<p>L’API proposée par cette RFC est globalement compatible avec celle actuellement en place pour la fonction <code class="highlighter-rouge">assert()</code> existante : il s’agit surtout d’améliorer celle-ci, notamment en supprimant complétement la génération et l’exécution du code de l’assertion en mode « production ».</p>
<p>Les votes se sont tenus du 19 au 26 février et <a href="http://news.php.net/php.internals/83912">nous avons exprimé un avis plutôt négatif sur <code class="highlighter-rouge">internals@</code></a>, considérant principalement que mélanger le code et les tests n’était pas l’approche qui nous semblait la meilleure et ne souhaitant donc pas encourager l’utilisation de <code class="highlighter-rouge">assert()</code>.<br />
Les résultats ont finalement été les suivants, cette RFC est donc passée :</p>
<ul>
<li>20 « oui » avec exceptions personnalisées</li>
<li>11 « oui » sans exception personnalisée</li>
<li>1 seul et unique « non »</li>
</ul>Pascal MARTINVoici une RFC destinée à servir principalement en environnements de développement :RFC: Allow error_handler callback parameters to be passed by reference2015-03-09T08:30:30+00:002015-03-09T08:30:30+00:00http://php-internals.afup.org/2015/03/09/rfc-allow-error_handler-callback-parameters-to-be-passed-by-reference<p>La <a href="https://wiki.php.net/rfc/error_handler_callback_parameters_passed_by_reference">RFC: Allow error_handler callback parameters to be passed by reference</a> avait pour objectif de permettre aux gestionnaires d’erreurs configurés via <code class="highlighter-rouge">set_error_handler()</code> de modifier les informations de l’erreur gérée, en passant ses valeurs par référence.</p>
<p>L’objectif était de pouvoir y passer des informations contextuelles de type identifiant stocké en session, URL parcourue lors de l’erreur, etc. de la manière suivante:</p>
<figure class="highlight"><pre><code class="language-php" data-lang="php"> <span class="nv">$_SESSION</span><span class="p">[</span><span class="s1">'username'</span><span class="p">]</span> <span class="o">=</span> <span class="s1">'john'</span><span class="p">;</span>
<span class="k">function</span> <span class="nf">myErrorHandler</span><span class="p">(</span><span class="nv">$errno</span><span class="p">,</span> <span class="o">&</span><span class="nv">$errstr</span><span class="p">,</span> <span class="nv">$errfile</span><span class="p">,</span> <span class="nv">$errline</span><span class="p">)</span>
<span class="p">{</span>
<span class="k">if</span> <span class="p">(</span><span class="nb">isset</span><span class="p">(</span><span class="nv">$_SESSION</span><span class="p">[</span><span class="s1">'username'</span><span class="p">]))</span> <span class="p">{</span>
<span class="nv">$errstr</span> <span class="o">.=</span> <span class="s1">', username: '</span><span class="o">.</span><span class="nv">$_SESSION</span><span class="p">[</span><span class="s1">'username'</span><span class="p">];</span>
<span class="p">}</span>
<span class="k">return</span> <span class="kc">false</span><span class="p">;</span> <span class="c1">// continue normal error handler
</span> <span class="p">}</span>
<span class="nb">set_error_handler</span><span class="p">(</span><span class="s1">'myErrorHandler'</span><span class="p">);</span></code></pre></figure>
<p>La RFC n’a pas convaincu et nos avis furent tous négatifs, principalement dû au fait que cette gestion pouvait être très facilement déléguée à la fonction utilisateur sans forcément avoir recours à des paramètres passés par référence. Nous avons donc posté en ce sens sur <a href="http://news.php.net/php.internals/84028">internals@</a>.</p>
<p>La RFC proposait deux choix possibles : passer uniquement le message d’erreur par référence, ou bien l’ensemble des paramètres. Quoi qu’il en soit, avec 19 voix contre et 4 pour, la RFC a été rejetée.</p>GuillaumeLa RFC: Allow error_handler callback parameters to be passed by reference avait pour objectif de permettre aux gestionnaires d’erreurs configurés via set_error_handler() de modifier les informations de l’erreur gérée, en passant ses valeurs par référence.RFC: Add pecl_http to core2015-03-05T08:30:16+00:002015-03-05T08:30:16+00:00http://php-internals.afup.org/2015/03/05/rfc-add-pecl_http-to-core<p>La <a href="https://wiki.php.net/rfc/pecl_http">RFC: Add <code class="highlighter-rouge">pecl_http</code> to core</a> avait pour objectif d’intégrer nativement à PHP 7 l’extension <a href="http://devel-m6w6.rhcloud.com/mdref/http"><code class="highlighter-rouge">pecl_http</code></a>. Cette extension permet de gérer des communications HTTP grâce à une implémentation orientée objet.</p>
<p>Néanmoins, la présence de <code class="highlighter-rouge">curl</code> permettant l’accès à la couche HTTP à bas-niveau ainsi que l’existence de bibliothèques comme <a href="https://github.com/guzzle/guzzle">Guzzle</a> apportant une implémentation orientée objet (en espace utilisateur, donc non liée au cycle de versions et de maintenance de PHP) nous a paru suffisant en l’état. De plus, l’extension <code class="highlighter-rouge">pecl_http</code> embarquait des dépendances qui seraient venues s’ajouter au cycle de maintenance de PHP. Nous avons donc <a href="http://news.php.net/php.internals/84030">posté en ce sens sur <code class="highlighter-rouge">internals@</code></a>.</p>
<p>Avec 9 voix pour et 23 voix contre, cette RFC a finalement été refusée : l’extension <code class="highlighter-rouge">pecl_http</code> restera disponible depuis PECL pour les intéressés, et ne sera pas distribuée avec PHP.</p>GuillaumeLa RFC: Add pecl_http to core avait pour objectif d’intégrer nativement à PHP 7 l’extension pecl_http. Cette extension permet de gérer des communications HTTP grâce à une implémentation orientée objet.