![\"PHP](\"https:\/\/kinsta.com\/wp-content\/uploads\/2020\/05\/php-8-released.png\")
\u00cates-vous pr\u00eat ? Plongeons dans le vif du sujet !<\/p>\n
PHP JIT (Compilation Just in Time)<\/h2>\n
La fonctionnalit\u00e9 la plus acclam\u00e9e de PHP 8 est la compilation \u00e0 la vol\u00e9e (Just In Time)<\/strong>. Qu’est-ce que JIT ?<\/p>\n La proposition de RFC<\/a> d\u00e9crit JIT comme suit :<\/p>\n \u00ab PHP JIT est mis en \u0153uvre comme une partie presque ind\u00e9pendante d’OPcache. Il peut \u00eatre activ\u00e9 \/ d\u00e9sactiv\u00e9 au moment de la compilation et de l’ex\u00e9cution de PHP. Lorsqu’il est activ\u00e9, le code natif des fichiers PHP est stock\u00e9 dans une r\u00e9gion suppl\u00e9mentaire de la m\u00e9moire partag\u00e9e d’OPcache et op_array\u2192opcodes[].handler(s) conserve les pointeurs vers les points d’entr\u00e9e du code JIT-ed \u00bb.<\/p><\/blockquote>\n Alors, comment en sommes-nous arriv\u00e9s \u00e0 JIT et quelle est la diff\u00e9rence entre JIT et OPcache ?<\/p>\n Pour mieux comprendre ce qu’est JIT pour PHP, examinons rapidement comment PHP<\/a> s\u2019ex\u00e9cute du code source au r\u00e9sultat final.<\/p>\n L’ex\u00e9cution de PHP est un processus en 4 \u00e9tapes :<\/p>\n L’image suivante montre une repr\u00e9sentation visuelle du processus d’ex\u00e9cution de base de PHP.<\/p>\n Alors, comment OPcache rend-il PHP plus rapide ? Et quels sont les changements dans le processus d’ex\u00e9cution avec JIT ?<\/p>\n PHP est un langage interpr\u00e9t\u00e9. Cela signifie que lorsqu’un script PHP est ex\u00e9cut\u00e9, l’interpr\u00e8teur analyse, compile et ex\u00e9cute le code \u00e0 chaque requ\u00eate. Cela peut entra\u00eener une perte de ressources CPU<\/a> et du temps suppl\u00e9mentaire.<\/p>\n C’est l\u00e0 que l’extension OPcache<\/a> entre en jeu :<\/p>\n \u00ab\u00a0OPcache am\u00e9liore les performances de PHP en stockant le bytecode des scripts pr\u00e9-compil\u00e9s dans la m\u00e9moire partag\u00e9e, ce qui \u00e9vite \u00e0 PHP de charger et d’analyser les scripts \u00e0 chaque requ\u00eate.\u00a0\u00bb<\/p><\/blockquote>\n Lorsque OPcache est activ\u00e9, l’interpr\u00e9teur PHP passe par les quatre \u00e9tapes mentionn\u00e9es ci-dessus uniquement la premi\u00e8re fois que le script est ex\u00e9cut\u00e9. Comme les bytecodes PHP sont stock\u00e9s dans la m\u00e9moire partag\u00e9e, ils sont imm\u00e9diatement disponibles en tant que repr\u00e9sentation interm\u00e9diaire de bas niveau et peuvent \u00eatre ex\u00e9cut\u00e9s imm\u00e9diatement sur la VM Zend.<\/p>\n \u00c0 partir de PHP 5.5, l’extension Zend OPcache est disponible par d\u00e9faut et vous pouvez v\u00e9rifier si vous l’avez correctement configur\u00e9e en appelant simplement Lecture sugg\u00e9r\u00e9e : Comment am\u00e9liorer la limite de m\u00e9moire PHP dans WordPress<\/a>.<\/p>\n OPcache a \u00e9t\u00e9 r\u00e9cemment am\u00e9lior\u00e9 avec la mise en \u0153uvre du pr\u00e9chargement<\/a>, une nouvelle fonctionnalit\u00e9 d’OPcache ajout\u00e9e avec PHP 7.4<\/a>. Le pr\u00e9chargement permet de stocker un ensemble sp\u00e9cifique de scripts dans la m\u00e9moire d’OPcache \u00ab\u00a0avant l’ex\u00e9cution de tout code d’application\u00a0\u00bb<\/i>, mais il n’apporte pas d’am\u00e9lioration tangible des performances des applications web typiques.<\/p>\n Vous pouvez en savoir plus sur le pr\u00e9chargement dans notre introduction \u00e0 PHP 7.4<\/a>.<\/p>\n Avec JIT, PHP fait un pas en avant.<\/p>\n M\u00eame si les opcodes se pr\u00e9sentent sous la forme d’une repr\u00e9sentation interm\u00e9diaire de bas niveau, ils doivent encore \u00eatre compil\u00e9s en code machine. JIT \u00ab\u00a0n’introduit pas de forme IR (Intermediate Representation) suppl\u00e9mentaire\u00a0\u00bb, mais utilise DynASM<\/a> (Assembleur dynamique pour les moteurs de g\u00e9n\u00e9ration de code) pour g\u00e9n\u00e9rer du code natif directement \u00e0 partir du byte-code PHP.<\/p>\n En bref, JIT traduit les parties chaudes du code interm\u00e9diaire en code machine<\/strong>. En contournant la compilation, il serait en mesure d’apporter des am\u00e9liorations consid\u00e9rables en termes de performances et d’utilisation de la m\u00e9moire.<\/p>\n Zeev Surasky, co-auteur de la proposition de PHP JIT, montre \u00e0 quel point les calculs seraient plus rapides avec JIT :<\/p>\n Mais, JIT am\u00e9liorerait-il efficacement les performances de WordPress<\/a> ?<\/p>\n Selon la RFC de JIT, la mise en \u0153uvre du compilateur \u00ab just in time \u00bb devrait am\u00e9liorer les performances de PHP. Mais conna\u00eetrions-nous vraiment de telles am\u00e9liorations dans des applications de la vie r\u00e9elle comme WordPress ?<\/p>\n Les premiers tests montrent que JIT permettrait de faire fonctionner beaucoup plus rapidement les charges de travail gourmandes en CPU, mais la RFC met en garde<\/a> :<\/p>\n \u00ab\u00a0… comme les tentatives pr\u00e9c\u00e9dentes – cela ne semble pas actuellement am\u00e9liorer de mani\u00e8re significative les applications de la vie r\u00e9elle comme WordPress (avec opcache.jit=1235 326 req\/sec vs 315 req\/sec).<\/p>\n Il est pr\u00e9vu de fournir un effort suppl\u00e9mentaire, en am\u00e9liorant JIT pour les applications de la vie r\u00e9elle, en utilisant le profilage et les optimisations sp\u00e9culatives\u00a0\u00bb.<\/p><\/blockquote>\n Avec JIT activ\u00e9, le code ne serait pas ex\u00e9cut\u00e9 par la VM Zend, mais par l’unit\u00e9 centrale elle-m\u00eame, ce qui am\u00e9liorerait la vitesse de calcul. Les applications web comme WordPress<\/a> reposent \u00e9galement sur d’autres facteurs comme le TTFB<\/a>, l’optimisation des bases de donn\u00e9es, les<\/a> requ\u00eates HTTP<\/a>, etc.<\/p>\n Ainsi, en ce qui concerne WordPress et les applications similaires, il ne faut pas s’attendre \u00e0 une grande augmentation de la vitesse d’ex\u00e9cution de PHP. N\u00e9anmoins, JIT pourrait apporter plusieurs avantages aux d\u00e9veloppeurs<\/a>.<\/p>\n Selon Nikita Popov<\/a> :<\/p>\n \u00ab\u00a0Les avantages du compilateur JIT sont en gros (et comme d\u00e9j\u00e0 soulign\u00e9 dans le RFC) :<\/p>\n Ainsi, alors que JIT n’apportera gu\u00e8re d’am\u00e9liorations consid\u00e9rables aux performances de WordPress, il fera passer PHP au niveau sup\u00e9rieur, en en faisant un langage dans lequel de nombreuses fonctions pourraient d\u00e9sormais \u00eatre \u00e9crites directement.<\/p>\n L’inconv\u00e9nient, cependant, serait la plus grande complexit\u00e9 qui peut entra\u00eener une augmentation des co\u00fbts de maintenance<\/a>, de stabilit\u00e9 et de d\u00e9bogage<\/a>. Selon Dmitry Stogov :<\/p>\n \u00ab JIT est extr\u00eamement simple, mais de toute fa\u00e7on il augmente le niveau de complexit\u00e9 du PHP, le risque de nouveaux types de bugs et le co\u00fbt du d\u00e9veloppement et de la maintenance. \u00bb<\/p><\/blockquote>\n La proposition d’inclure JIT dans PHP 8 a \u00e9t\u00e9 adopt\u00e9e par 50 voix contre 2.<\/p>\n\n En dehors de JIT, nous pouvons nous attendre \u00e0 de nombreuses fonctionnalit\u00e9s et am\u00e9liorations avec PHP 8. La liste suivante est notre s\u00e9lection des ajouts et changements \u00e0 venir qui devraient rendre PHP plus fiable et plus efficace.<\/p>\n Suite \u00e0 une discussion en cours sur la fa\u00e7on d’am\u00e9liorer l’ergonomie des objets en PHP<\/a>, le RFC \u00ab\u00a0Constructor Property Promotion\u00a0\u00bb<\/a> propose une nouvelle syntaxe plus concise qui simplifiera la d\u00e9claration de propri\u00e9t\u00e9, la rendant plus courte et moins redondante.<\/p>\n Cette proposition ne concerne que les \u201cpromoted parameters<\/strong>\u201d ou param\u00e8tres promus, c’est-\u00e0-dire les param\u00e8tres de m\u00e9thode pr\u00e9fix\u00e9s par des mots-cl\u00e9s de visibilit\u00e9 publique<\/strong>, prot\u00e9g\u00e9e et priv\u00e9e<\/strong>.<\/p>\n Actuellement, toutes les propri\u00e9t\u00e9s doivent \u00eatre r\u00e9p\u00e9t\u00e9es plusieurs fois (au moins quatre fois) avant que nous puissions les utiliser avec des objets. Consid\u00e9rons l’exemple suivant, tir\u00e9 du RFC :<\/p>\n Selon Nikita Popov, l’auteure du RFC, nous devons \u00e9crire le nom de la propri\u00e9t\u00e9 au moins quatre fois \u00e0 trois endroits diff\u00e9rents : la d\u00e9claration de propri\u00e9t\u00e9, les param\u00e8tres du constructeur et l’affectation de la propri\u00e9t\u00e9. Cette syntaxe n’est pas particuli\u00e8rement utilisable, surtout dans les classes ayant un bon nombre de propri\u00e9t\u00e9s et des noms plus descriptifs.<\/p>\n Ce RFC propose de fusionner le constructeur et la d\u00e9finition des param\u00e8tres. Ainsi, \u00e0 partir de PHP 8, nous disposons d’une fa\u00e7on plus utilisable de d\u00e9clarer les param\u00e8tres et le code vu ci-dessus peut changer comme indiqu\u00e9 ci-dessous :<\/p>\n Et c’est tout. Nous avons donc une nouvelle fa\u00e7on de promouvoir les propri\u00e9t\u00e9s qui est plus courte, plus lisible et moins sujette aux erreurs. Selon Nikita<\/a> :<\/p>\n C’est une simple transformation syntaxique que nous faisons. Mais cela r\u00e9duit la quantit\u00e9 de code passe-partout que vous devez \u00e9crire pour les objets de valeur en particulier…<\/p><\/blockquote>\n La d\u00e9claration de propri\u00e9t\u00e9 est transform\u00e9e comme nous avions explicitement d\u00e9clar\u00e9 ces propri\u00e9t\u00e9s et nous pouvons utiliser l’API Reflection<\/a> pour introspecter les d\u00e9finitions de propri\u00e9t\u00e9 avant l’ex\u00e9cution (voir Desugaring<\/a>) :<\/p>\n La r\u00e9flexion (et autres m\u00e9canismes d’introspection) permettra d’observer l’\u00e9tat apr\u00e8s le \u201cdesugaring\u201d. Cela signifie que les propri\u00e9t\u00e9s promues appara\u00eetront de la m\u00eame mani\u00e8re que les propri\u00e9t\u00e9s explicitement d\u00e9clar\u00e9es, et que les arguments du constructeur promu appara\u00eetront comme des arguments du constructeur ordinaire. Nous n’avons aucune limite \u00e0 l’utilisation de l’h\u00e9ritage en conjonction avec des param\u00e8tres promus. De toute fa\u00e7on, il n’y a pas de relation particuli\u00e8re entre les constructeurs de classes de parents et d’enfants. Selon Nikita<\/a> :<\/p>\n Habituellement, nous disons que les m\u00e9thodes doivent toujours \u00eatre compatibles avec la m\u00e9thode m\u00e8re. […] mais cette r\u00e8gle ne s’applique pas au constructeur. Ainsi, le constructeur appartient r\u00e9ellement \u00e0 une seule classe, et les constructeurs entre la classe parent et la classe enfant n’ont pas \u00e0 \u00eatre compatibles d’une quelconque mani\u00e8re. Voici un exemple:<\/p>\n Les propri\u00e9t\u00e9s promues sont autoris\u00e9es dans les constructeurs et les traits non abstraits, mais il y a plusieurs limitations qui m\u00e9ritent d’\u00eatre mentionn\u00e9es ici.<\/p>\n Les propri\u00e9t\u00e9s promues ne sont pas autoris\u00e9es dans les classes et les interfaces abstraites :<\/p>\n L’une des contraintes les plus notables est li\u00e9e \u00e0 l’annulabilit\u00e9. Auparavant, lorsque nous utilisions un type qui n’\u00e9tait pas explicitement annulable, mais avec une valeur par d\u00e9faut nulle, le type \u00e9tait implicitement annulable. Mais avec les types de propri\u00e9t\u00e9, nous n’avons pas ce comportement implicite car les param\u00e8tres promus n\u00e9cessitent une d\u00e9claration de propri\u00e9t\u00e9, et le type annulable doit \u00eatre explicitement d\u00e9clar\u00e9. Voir l’exemple suivant de la RFC :<\/p>\n Comme le type callable n’est pas pris en charge pour les propri\u00e9t\u00e9s<\/a>, nous ne sommes pas autoris\u00e9s \u00e0 utiliser le type callable dans les propri\u00e9t\u00e9s promues :<\/p>\n Seul un mot-cl\u00e9 de visibilit\u00e9 peut \u00eatre utilis\u00e9 avec les param\u00e8tres promus, donc la d\u00e9claration des propri\u00e9t\u00e9s du constructeur avec le mot-cl\u00e9 Nous pouvons combiner des propri\u00e9t\u00e9s promues et des propri\u00e9t\u00e9s explicites dans la m\u00eame classe, mais les propri\u00e9t\u00e9s ne peuvent pas \u00eatre d\u00e9clar\u00e9es deux fois :<\/p>\n La raison en est que le type d\u00e9clar\u00e9 est diff\u00e9rent du param\u00e8tre variadique, qui est en fait un tableau :<\/p>\n Pour en savoir plus sur Costructor Property Promotion, \u00e9coutez cette interview de Nikita Popov<\/a>. Pour un aper\u00e7u d\u00e9taill\u00e9 de l’ergonomie des objets en PHP, voir ce post<\/a> et l’interview suivante avec Larry Garfield<\/a>.<\/p>\n Les traits<\/a> sont d\u00e9finis comme \u00ab\u00a0un m\u00e9canisme de r\u00e9utilisation de code dans des langages \u00e0 h\u00e9ritage unique tels que PHP\u00a0\u00bb. Ils sont g\u00e9n\u00e9ralement utilis\u00e9s pour d\u00e9clarer des m\u00e9thodes qui peuvent \u00eatre utilis\u00e9es dans plusieurs classes.<\/p>\n Un trait peut \u00e9galement contenir des m\u00e9thodes abstraites. Ces m\u00e9thodes d\u00e9clarent simplement la signature de la m\u00e9thode, mais l’impl\u00e9mentation de la m\u00e9thode doit \u00eatre faite au sein de la classe qui utilise le trait.<\/p>\n Selon le manuel de PHP<\/a>,<\/p>\n \u00ab\u00a0Les traits prennent en charge l’utilisation de m\u00e9thodes abstraites afin d’imposer des exigences \u00e0 la classe exposante\u00a0\u00bb.<\/p><\/blockquote>\n Cela signifie \u00e9galement que les signatures des m\u00e9thodes doivent correspondre. En d’autres termes, le type et le nombre d’arguments n\u00e9cessaires doivent \u00eatre les m\u00eames<\/a>.<\/p>\n Quoi qu’il en soit, selon Nikita Popov,<\/a> auteur de la RFC, la validation des signatures n’est actuellement impos\u00e9e que de mani\u00e8re ponctuelle :<\/p>\n L’exemple suivant de Nikita concerne le premier cas (signature non impos\u00e9e) :<\/p>\n Cela \u00e9tant dit, cette RFC<\/a> propose de toujours lancer une erreur fatale si la m\u00e9thode de mise en \u0153uvre n’est pas compatible avec la m\u00e9thode des traits abstraits, quelle que soit son origine :<\/p>\n Cette RFC a \u00e9t\u00e9 approuv\u00e9e \u00e0 l’unanimit\u00e9.<\/p>\n En PHP, les erreurs d’h\u00e9ritage d\u00fbes \u00e0 des signatures de m\u00e9thodes incompatibles d\u00e9clenchent soit une erreur fatale, soit un avertissement selon la cause de l’erreur.<\/p>\n Si une classe impl\u00e9mente une interface, les signatures de m\u00e9thodes incompatibles entra\u00eenent une erreur fatale. Selon la documentation sur les interfaces objet<\/a> :<\/p>\n \u00ab\u00a0La classe qui impl\u00e9mente l’interface doit utiliser une signature de m\u00e9thode qui est compatible avec le LSP (Liskov Substitution Principle). Ne pas le faire entra\u00eenera une erreur fatale\u00a0\u00bb.<\/p><\/blockquote>\n Voici un exemple d’erreur d’h\u00e9ritage avec une interface<\/a> :<\/p>\n Dans PHP 7.4, le code ci-dessus entra\u00eenerait l’erreur suivante :<\/p>\n Une fonction dans une classe enfant avec une signature incompatible lancerait un avertissement. Voir le code suivant de la RFC :<\/p>\n Dans PHP 7.4, le code ci-dessus lancerait simplement un avertissement :<\/p>\n Or, cette RFC<\/a> propose de toujours lancer une erreur fatale pour les signatures de m\u00e9thodes incompatibles. Avec PHP 8, le code que nous avons vu plus haut d\u00e9clencherait ce qui suit :<\/p>\n En PHP, si un tableau commence par un index n\u00e9gatif ( Dans PHP 7.4, le r\u00e9sultat serait le suivant :<\/p>\n Maintenant, cette RFC<\/a> propose de changer les choses de mani\u00e8re \u00e0 ce que le deuxi\u00e8me indice soit Dans PHP 8, le code ci-dessus donnerait le tableau suivant :<\/p>\n Avec PHP 8, les tableaux commen\u00e7ant par un index n\u00e9gatif modifient leur comportement. Pour en savoir plus sur les incompatibilit\u00e9s ascendantes dans la RFC<\/a>.<\/p>\n Les types d’union<\/a> (Union Types) acceptent des valeurs qui peuvent \u00eatre de diff\u00e9rents types. Actuellement, PHP ne fournit pas de support pour les types d’union, \u00e0 l’exception de la syntaxe Avant PHP 8, les types d’Union ne pouvaient \u00eatre sp\u00e9cifi\u00e9s que dans les annotations phpdoc, comme le montre l’exemple suivant de la RFC :<\/p>\n Maintenant, la RFC des types d\u2019Union 2.0<\/a> propose d’ajouter la prise en charge des types d’Union dans les signatures de fonctions, de sorte que nous ne d\u00e9pendrons plus de la documentation en ligne, mais d\u00e9finirons les types d’Union avec une syntaxe Comme l’explique Nikita Popov dans la RFC,<\/p>\n \u00ab La prise en charge des types d\u2019Union dans le language nous permet de d\u00e9placer davantage d’informations de type du phpdoc vers les signatures de fonction, avec les avantages habituels que cela apporte :<\/p>\n Les types d’Union prennent en charge tous les types disponibles, avec certaines limitations :<\/p>\n Vous pouvez en savoir plus sur les types d’Union V2<\/a> dans la RFC.<\/p>\n Lors du passage d’un param\u00e8tre de type ill\u00e9gal, les fonctions\u00a0internes<\/a> et celles d\u00e9finies par l’utilisateur<\/a> se comportent diff\u00e9remment.<\/p>\n Les fonctions d\u00e9finies par l’utilisateur provoquent une Il en r\u00e9sulterait l’avertissement suivant :<\/p>\n Si Cette situation entra\u00eenerait un certain nombre de probl\u00e8mes bien expliqu\u00e9s dans \n
![\"Processus](\"https:\/\/kinsta.com\/fr\/wp-content\/uploads\/sites\/4\/2020\/05\/processus-execution-base-php.png\")
L’extension OPcache<\/h3>\n
![\"Processus](\"https:\/\/kinsta.com\/fr\/wp-content\/uploads\/sites\/4\/2020\/05\/processus-execution-php-opcache-active.png\")
phpinfo()<\/code><\/a> depuis un script sur votre serveur ou en consultant votre fichier php.ini (voir les\u00a0r\u00e9glages de configuration d’OPcache<\/a>).<\/p>\n![\"Section](\"https:\/\/kinsta.com\/fr\/wp-content\/uploads\/sites\/4\/2020\/05\/section-zend-opcache-page-phpinfo.jpg\")
Pr\u00e9chargement<\/h3>\n
JIT – La compilation \u00e0 la vol\u00e9e<\/h3>\n
JIT pour les applications web en direct<\/h3>\n
![\"PHP](\"https:\/\/kinsta.com\/wp-content\/uploads\/2020\/05\/php-8-performance-diagram.png\")
\n
Am\u00e9liorations et nouvelles fonctionnalit\u00e9s de PHP 8<\/h2>\n
Constructor Property Promotion<\/h3>\n
class Point {\n public int $x;\n public int $y;\n public int $z;\n\n public function __construct(\n int $x = 0,\n int $y = 0,\n int $z = 0,\n ) {\n $this->x = $x;\n $this->y = $y;\n $this->z = $z;\n }\n}<\/code><\/span><\/pre>\nclass Point {\n public function __construct(\n public int $x = 0,\n public int $y = 0,\n public int $z = 0,\n ) {}\n}<\/code><\/span><\/pre>\n
\n<\/span><\/p><\/blockquote>\n\/\/ before desugaring\nclass Point {\n public function __construct(public int $x = 0) {}\n}\n\n\/\/ after desugaring\nclass Point {\n public int $x;\n\n public function __construct(int $x = 0) {\n $this->x = $x;\n }\n}<\/code><\/span><\/pre>\nInheritance<\/h4>\n
\n<\/span><\/p><\/blockquote>\nclass Test {\n public function __construct(\n public int $x = 0\n ) {}\n}\n\nclass Child extends Test {\n public function __construct(\n $x, \n public int $y = 0,\n public int $z = 0,\n ) {\n parent::__construct($x);\n }\n}<\/code><\/span><\/pre>\nCe qui n’est pas autoris\u00e9 avec les propri\u00e9t\u00e9s promues
\n<\/span><\/h4>\nConstructeurs abstraits
\n<\/span><\/h5>\nabstract class Test {\n \/\/ Error: Abstract constructor.\n abstract public function __construct(private $x);\n}\n \ninterface Test {\n \/\/ Error: Abstract constructor.\n public function __construct(private $x);\n}<\/code><\/span><\/pre>\nNullabilit\u00e9
\n<\/span><\/h5>\nclass Test {\n \/\/ Error: Using null default on non-nullable property\n public function __construct(public Type $prop = null) {}\n\n \/\/ Correct: Make the type explicitly nullable instead\n public function __construct(public ?Type $prop = null) {}\n}<\/code><\/span><\/pre>\nCallable Type<\/h5>\n
class Test {\n \/\/ Error: Callable type not supported for properties.\n public function __construct(public callable $callback) {}\n}<\/code><\/span><\/pre>\nLe mot-cl\u00e9 var n’est pas autoris\u00e9
\n<\/span><\/h5>\nvar<\/code> n’est pas autoris\u00e9e (voir l’exemple suivant du RFC) :<\/p>\nclass Test {\n \/\/ Error: \"var\" keyword is not supported.\n public function __construct(var $prop) {}\n}<\/code><\/span><\/pre>\nAucune duplication autoris\u00e9
\n<\/span><\/h5>\nclass Test {\n public string $prop;\n public int $explicitProp;\n\n \/\/ Correct\n public function __construct(public int $promotedProp, int $arg) {\n $this->explicitProp = $arg;\n }\n\n \/\/ Error: Redeclaration of property.\n public function __construct(public string $prop) {}\n}<\/code><\/span><\/pre>\nLes param\u00e8tres variadiques ne sont pas autoris\u00e9s<\/h5>\n
class Test {\n \/\/ Error: Variadic parameter.\n public function __construct(public string ...$strings) {}\n}<\/code><\/span><\/pre>\nLectures compl\u00e9mentaires
\n<\/span><\/h4>\nValidation pour les m\u00e9thodes de traits abstraits<\/h3>\n
\n
\n
trait T {\n\tabstract public function test(int $x);\n}\n \nclass C {\n\tuse T;\n\n\t\/\/ Allowed, but shouldn't be due to invalid type.\n\tpublic function test(string $x) {}\n}<\/code><\/pre>\nFatal error: Declaration of C::test(string $x) must be compatible with T::test(int $x) in \/path\/to\/your\/test.php on line 10<\/code><\/pre>\nSignatures de m\u00e9thodes incompatibles<\/h3>\n
interface I {\n\tpublic function method(array $a);\n}\nclass C implements I {\n\tpublic function method(int $a) {}\n}<\/code><\/pre>\nFatal error: Declaration of C::method(int $a) must be compatible with I::method(array $a) in \/path\/to\/your\/test.php on line 7<\/code><\/pre>\nclass C1 {\n\tpublic function method(array $a) {}\n}\nclass C2 extends C1 {\n\tpublic function method(int $a) {}\n}<\/code><\/pre>\nWarning: Declaration of C2::method(int $a) should be compatible with C1::method(array $a) in \/path\/to\/your\/test.php on line 7<\/code><\/pre>\nFatal error: Declaration of C2::method(int $a) must be compatible with C1::method(array $a) in \/path\/to\/your\/test.php on line 7<\/code><\/pre>\nTableaux commen\u00e7ant par un index n\u00e9gatif<\/h3>\n
start_index < 0<\/code>), les indices suivants partiront de 0 (plus d’informations \u00e0 ce sujet dans la documentation de array_fill<\/code>)<\/a>. Regardez l’exemple suivant :<\/p>\n$a = array_fill(-5, 4, true);\nvar_dump($a);<\/code><\/pre>\narray(4) {\n\t[-5]=>\n\tbool(true)\n\t[0]=>\n\tbool(true)\n\t[1]=>\n\tbool(true)\n\t[2]=>\n\tbool(true)\n}<\/code><\/pre>\nstart_index + 1<\/code>, quelle que soit la valeur de start_index<\/code>.<\/p>\narray(4) {\n\t[-5]=>\n\tbool(true)\n\t[-4]=>\n\tbool(true)\n\t[-3]=>\n\tbool(true)\n\t[-2]=>\n\tbool(true)\n}<\/code><\/pre>\nTypes d\u2019union 2.0<\/h3>\n
?Type<\/code> et du type sp\u00e9cial iterable<\/code>.<\/p>\nclass Number {\n\t\/**\n\t * @var int|float $number\n\t *\/\n\tprivate $number;\n\n\t\/**\n\t * @param int|float $number\n\t *\/\n\tpublic function setNumber($number) {\n\t\t$this->number = $number;\n\t}\n\n\t\/**\n\t * @return int|float\n\t *\/\n\tpublic function getNumber() {\n\t\treturn $this->number;\n\t}\n}<\/code><\/pre>\nT1|T2|...<\/code> \u00e0 la place :<\/p>\nclass Number {\n\tprivate int|float $number;\n\n\tpublic function setNumber(int|float $number): void {\n\t\t$this->number = $number;\n\t}\n\n\tpublic function getNumber(): int|float {\n\t\treturn $this->number;\n\t}\n}<\/code><\/pre>\n\n
\n
void<\/code> ne pourrait pas faire partie d’une union, car void<\/code> signifie qu’une fonction ne retourne aucune valeur<\/a>.<\/li>\nnull<\/code> n\u2019est pris en charge que dans les types d\u2019union, mais son utilisation en tant que type autonome n’est pas autoris\u00e9e.<\/li>\n?T<\/code>) est \u00e9galement autoris\u00e9e, c’est-\u00e0-dire T|null<\/code>, mais nous ne sommes pas autoris\u00e9s \u00e0 inclure la notation ?T<\/code> dans les types d’union (?T1|T2<\/code> n\u2019est pas autoris\u00e9 et nous devrions utiliser T1|T2|null<\/code> \u00e0 la place).<\/li>\nstrpos()<\/code>, strstr()<\/code>, substr()<\/code>, etc.) incluent false<\/code> parmi les types de retour possibles, le pseudo-type false<\/code> est \u00e9galement pris en charge.<\/li>\n<\/ul>\nErreurs de type coh\u00e9rentes pour les fonctions internes<\/h3>\n
TypeError<\/code>, mais les fonctions internes se comportent de diff\u00e9rentes mani\u00e8res, selon plusieurs conditions. Quoi qu’il en soit, le comportement typique est de lancer un avertissement et de retourner null<\/code>. Voir l’exemple suivant en PHP 7.4 :<\/p>\nvar_dump(strlen(new stdClass));<\/code><\/pre>\nWarning: strlen() expects parameter 1 to be string, object given in \/path\/to\/your\/test.php on line 4\nNULL<\/code><\/pre>\nstrict_types<\/code> est activ\u00e9, ou si les informations sur les arguments sp\u00e9cifient les types, le comportement sera diff\u00e9rent. Dans de tels sc\u00e9narios, l’erreur de type est d\u00e9tect\u00e9e et entra\u00eene une TypeError<\/code>.<\/p>\nla section des questions de la RFC<\/code>.<\/p>\n