PHP : la version 8.2 pour plus de performances
Les techniquement null et false pourraient être considérés comme des types valides par eux-mêmes. Les exemples courants sont les fonctions intégrées de PHP, où false est utilisé comme type de retour en cas d'erreur. Notons que l'utilisation de false dans un type union était déjà possible ; mais en PHP 8.2, il peut être utilisé comme un type autonome.
Selon Brent Roose, de nombreux développeurs, dont lui-même, sont un peu méfiants en regardant la RFC qui traite de True et False. « Elle ne prend pas en charge true en tant que type autonome, et les types ne devraient-ils pas représenter des catégories plutôt que des valeurs individuelles ? », s’interroge-t-il. « Il s'avère qu'il existe un concept appelé type unitaire dans les systèmes de types, qui sont des types qui ne permettent qu'une seule valeur. Mais est-ce vraiment utile, et est-ce que cela encourage la conception de logiciels propres ? Peut-être, peut-être pas. », ajoute-til. Un type null autonome est un peu plus logique : null peut être considéré comme une catégorie en soi et pas seulement comme une valeur dans une catégorie.
Il est logique que NullPost: :getAuthor() puisse dire qu'il ne retournera jamais que null, au lieu de null ou string, ce qui n'était pas possible auparavant.
Brent Roose recommande d’éviter d'utiliser false comme un type autonome pour transmettre un état d'erreur « je pense qu'il y a de meilleures solutions pour résoudre de tels problèmes. »
Les propriétés dynamiques sont dépréciées en PHP 8.2, et lèveront une ErrorException en PHP 9.0. Rappelons que les propriétés dynamiques sont des propriétés qui ne sont pas présentes sur un objet, mais qui sont néanmoins définies ou obtenues. Les classes implémentant __get et __set fonctionneront toujours comme prévu.
Pour Brent Roose, le PHP était autrefois un langage très dynamique, mais il s'est éloigné de cet état d'esprit depuis un certain temps déjà. Ce dernier pense que c'est une bonne chose d'adopter des règles plus strictes et de s'appuyer sur l'analyse statique partout où cela est possible, car cela permet aux développeurs d'écrire un meilleur code.
Une pratique courante dans toute base de code est d'envoyer les erreurs de production à un service qui en garde la trace et notifie les développeurs lorsque quelque chose ne va pas. Cette pratique implique souvent l'envoi de traces de pile par câble à un service tiers. Il y a cependant des cas où ces traces de pile peuvent inclure des informations sensibles telles que des variables d'environnement, des mots de passe ou des noms d'utilisateur.
PHP 8.2 permet de marquer ces « paramètres sensibles » avec un attribut, de sorte que l'utilisateur n'ait pas à se soucier de leur présence dans les piles de traces lorsque quelque chose ne va pas. Voici un exemple tiré de la RFC.
Un autre changement, bien qu'ayant un impact légèrement plus faible, est que les callablespartiellement supportés sont maintenant dépréciés également. Les callables partiellement supportés sont des callables qui peuvent être appelés en utilisant call_user_func($callable), mais pas en appelant $callable() directement. La liste de ces types de callablesest assez courte, d'ailleurs :
"self::method"
"parent::method"
"static::method"
["self", "method"]
["parent", "method"]
["static", "method"]
["Foo", "Bar::method"]
[new Foo, "Bar::method"]
La raison de ce choix ? Pour certains programmeurs, il s'agit là d'un pas dans la bonne direction vers la possibilité d'utiliser callable pour les propriétés typées. C'est bien expliqué dans la RFC.
« tous ces callables sont dépendants du contexte. La méthode à laquelle self::method fait référence dépend de la classe à partir de laquelle l'appel ou la vérification de callability est effectué. En pratique, cela vaut également pour les deux derniers cas, lorsqu'ils sont utilisés sous la forme [new Foo, "parent::method"].
La réduction de la dépendance contextuelle des callables est l'objectif secondaire de ce RFC. Après cette RFC, la seule dépendance de portée qui reste est la visibilité de la méthode : Foo::bar peut être visible dans une portée, mais pas dans une autre. Si les callables devaient être limités aux méthodes publiques à l'avenir (tandis que les méthodes privées devraient utiliser des callables de première classe ou Closure::fromCallable() pour être rendues indépendantes de la portée), alors le type callable deviendrait bien défini et pourrait être utilisé comme un type de propriété. Cependant, les modifications de la gestion de la visibilité ne sont pas proposées dans le cadre de ce RFC. »
Source : Brent Roose's blog
Selon Brent Roose, de nombreux développeurs, dont lui-même, sont un peu méfiants en regardant la RFC qui traite de True et False. « Elle ne prend pas en charge true en tant que type autonome, et les types ne devraient-ils pas représenter des catégories plutôt que des valeurs individuelles ? », s’interroge-t-il. « Il s'avère qu'il existe un concept appelé type unitaire dans les systèmes de types, qui sont des types qui ne permettent qu'une seule valeur. Mais est-ce vraiment utile, et est-ce que cela encourage la conception de logiciels propres ? Peut-être, peut-être pas. », ajoute-til. Un type null autonome est un peu plus logique : null peut être considéré comme une catégorie en soi et pas seulement comme une valeur dans une catégorie.
Il est logique que NullPost: :getAuthor() puisse dire qu'il ne retournera jamais que null, au lieu de null ou string, ce qui n'était pas possible auparavant.
Brent Roose recommande d’éviter d'utiliser false comme un type autonome pour transmettre un état d'erreur « je pense qu'il y a de meilleures solutions pour résoudre de tels problèmes. »
Les propriétés dynamiques sont dépréciées en PHP 8.2, et lèveront une ErrorException en PHP 9.0. Rappelons que les propriétés dynamiques sont des propriétés qui ne sont pas présentes sur un objet, mais qui sont néanmoins définies ou obtenues. Les classes implémentant __get et __set fonctionneront toujours comme prévu.
Pour Brent Roose, le PHP était autrefois un langage très dynamique, mais il s'est éloigné de cet état d'esprit depuis un certain temps déjà. Ce dernier pense que c'est une bonne chose d'adopter des règles plus strictes et de s'appuyer sur l'analyse statique partout où cela est possible, car cela permet aux développeurs d'écrire un meilleur code.
Une pratique courante dans toute base de code est d'envoyer les erreurs de production à un service qui en garde la trace et notifie les développeurs lorsque quelque chose ne va pas. Cette pratique implique souvent l'envoi de traces de pile par câble à un service tiers. Il y a cependant des cas où ces traces de pile peuvent inclure des informations sensibles telles que des variables d'environnement, des mots de passe ou des noms d'utilisateur.
PHP 8.2 permet de marquer ces « paramètres sensibles » avec un attribut, de sorte que l'utilisateur n'ait pas à se soucier de leur présence dans les piles de traces lorsque quelque chose ne va pas. Voici un exemple tiré de la RFC.
Un autre changement, bien qu'ayant un impact légèrement plus faible, est que les callablespartiellement supportés sont maintenant dépréciés également. Les callables partiellement supportés sont des callables qui peuvent être appelés en utilisant call_user_func($callable), mais pas en appelant $callable() directement. La liste de ces types de callablesest assez courte, d'ailleurs :
"self::method"
"parent::method"
"static::method"
["self", "method"]
["parent", "method"]
["static", "method"]
["Foo", "Bar::method"]
[new Foo, "Bar::method"]
La raison de ce choix ? Pour certains programmeurs, il s'agit là d'un pas dans la bonne direction vers la possibilité d'utiliser callable pour les propriétés typées. C'est bien expliqué dans la RFC.
« tous ces callables sont dépendants du contexte. La méthode à laquelle self::method fait référence dépend de la classe à partir de laquelle l'appel ou la vérification de callability est effectué. En pratique, cela vaut également pour les deux derniers cas, lorsqu'ils sont utilisés sous la forme [new Foo, "parent::method"].
La réduction de la dépendance contextuelle des callables est l'objectif secondaire de ce RFC. Après cette RFC, la seule dépendance de portée qui reste est la visibilité de la méthode : Foo::bar peut être visible dans une portée, mais pas dans une autre. Si les callables devaient être limités aux méthodes publiques à l'avenir (tandis que les méthodes privées devraient utiliser des callables de première classe ou Closure::fromCallable() pour être rendues indépendantes de la portée), alors le type callable deviendrait bien défini et pourrait être utilisé comme un type de propriété. Cependant, les modifications de la gestion de la visibilité ne sont pas proposées dans le cadre de ce RFC. »
Source : Brent Roose's blog
