Discussion :

[Alexandre T]

Bonjour à tous,

Nouvel article dans la rubrique PHP : Les nouveautés de PHP8 !

Comme l'article vous y invite, n'hésitez pas à donner votre avis sur :

• les types à choix multiples ;
• les optimisations grâce au nouveau compilateur à la volée ;
• les attributs ;
• etc.

Bref, n'hésitez pas à donner votre avis sur l'ensemble des nouveautés de PHP8.

Merci !

[grunk]

mixed et union type : Enfin !
Qu'est ce que c'est lourd actuellement d'avoir quais la totalité du code typé correctement sauf quelques parties qui retourne des type mix.

Les weakmap j'ai du mal à voir leur intérêt en PHP . Autant dans des langages comme java ou le code vie longtemps ca a du sens , autant en php où tout disparaît une fois le code exécuté j'ai plus de mal. Jamais en PHP je me suis retrouvé dans le besoin d'une weakmap.

Pour les constructeurs promouvants , comme déjà dit ici, je suis mitigé

[Alexandre T]

mixed et union type : Enfin !
Qu'est ce que c'est lourd actuellement d'avoir quais la totalité du code typé correctement sauf quelques parties qui retourne des type mix.

Oui je partage totalement ton point de vue !

Les weakmap j'ai du mal à voir leur intérêt en PHP . Autant dans des langages comme java ou le code vie longtemps ca a du sens , autant en php où tout disparaît une fois le code exécuté j'ai plus de mal. Jamais en PHP je me suis retrouvé dans le besoin d'une weakmap.

Voici un exemple, dis-moi s'il te parle : Admettons que tu veuilles aussi gérer l'état d'une liste d'objets (par exemple l'état de publication d'un ensemble d'articles). Tu crées une instance état à partir de la classe WeakMap. Tu passes chacun de tes objets en clé de la WeakMap et tu peux mémoriser son état (cet état n'est pas forcément une chaine de caractère, cela peut-être un objet !). Quand l'objet saute, la WeakMap reste à jour, car elle perd la clé ! Quand tu veux parcourir ta liste d'états, c'est facile, car la WeakMap est itérable.

Voici la documentation en français de la WeakMap

Pour les constructeurs promouvants , comme déjà dit ici, je suis mitigé

Sur ce point, je ne suis pas tout à faire d'accord avec toi. Je te rejoins sur la lecture d'un constructeur qui peut se compliquer surtout si le développeur mixe des arguments à promouvoir et des arguments normaux. C'est un coup à se casser les dents. Mais, je pense que dans le cas d'un DTO comme je l'ai noté dans mon exemple, le code devient bien plus clair. Ce serait dommage de s'en priver. C'est un peu comme les opérateurs '??' '' qui simplifie le code en une seule ligne, c'est bien, tant qu'on n'en abuse pas.

[grunk]

Je comprend bien l'intérêt des références faibles dans des langages comme java ou c++ où je les utilises relativement souvent. Mais c'est parce que mon code vie longtemps, que j'ai plusieurs thread qui peuvent venir agir sur mes objets ,que je veux parfois libérer au plus vite des objets ou que je veux éviter une leak éventuelle à cause d'une référence .
Mais en PHP comme 99% du temps mon code ne vie que quelques milliseconde , je n'ai pas de réel besoin de référence faible. Au pire ca leak jusqu'à la fin de l'execution de mon script et on en parle plus.

[Alexandre T]

Pardon, j'avais mal compris ta remarque. Oui tu as raison, les applications développées en PHP en n'ont moins besoin que celles développées en Java ! À part les commandes back-end de Symfony pour gérer les workflows, je ne vois pas.

[emilie77]

Merci beaucoup!

[Loralina]

Bonjour,

Sur ce point, je ne suis pas tout à faire d'accord avec toi. Je te rejoins sur la lecture d'un constructeur qui peut se compliquer surtout si le développeur mixe des arguments à promouvoir et des arguments normaux. C'est un coup à se casser les dents. Mais, je pense que dans le cas d'un DTO comme je l'ai noté dans mon exemple, le code devient bien plus clair. Ce serait dommage de s'en priver. C'est un peu comme les opérateurs '??' '' qui simplifie le code en une seule ligne, c'est bien, tant qu'on n'en abuse pas.

Oui, sauf que cette mise à jour sera accessible à tous, pas seulement à ceux qui sauront l'utiliser à bon escient.

La limite entre ce qui est abusif et ce qui ne l'est pas est floue et subjective.
Il y aura sûrement des cas intermédiaires où le choix ne sera pas évident ou que la tentation de gagner des lignes l'emportera.
Or, cette possibilité peut aboutir à une présentation disparate et peu cohérente des propriétés (dans une même classe ou d'une classe par rapport à une autre).

De plus, la réalité est souvent piégeuse :
En cours de réalisation, la conception s'affine, les besoins changent, un dysfonctionnement implique un correctif etc.
Une mise à jour simple et rapide (on n'a pas toujours le temps ni la motivation) donnera souvent un code moins joli qu'espéré, sur la forme ou le fond.
C'est à dire que certains choix initiaux paraissent inappropriés dans un deuxième temps suite à une mise à jour, mais qu'on ne peut/veut pas tout reprendre.

Cela peut tout à fait se produire avec cette nouvelle possibilité.
Après, ça reste de la forme, donc pas gravissime à priori.
Et bien sûr, on ne peut pas interdire toute nouveauté sous prétexte qu'il y aura de mauvaises utilisations.
Mais disons qu'on peut tout de même nuancer l'enthousiasme.

[Alexandre T]

Tu as tout-à-fait raison. La réalité est souvent piégeuse et en pratique on est vite débordé, surtout en maintenance. C'est difficile de définir le juste milieu. Pour ma part, j'utilise PHPCsFixer, PHP Mess Detector et PHP Code sniffer. J'ai défini des règles pour nos projets, on les déclare comme script dans composer et on les ajoute à nos tests d'intégration. Du coup, quand un développeur qui participe au projet ne respecte pas les consignes, cela le lui signale aussitôt. C'est un enfer à gérer sur d'anciens projets, mais sur tout nouveau projet, on le met dès le début et ça marche plutôt bien. Maintenant, va falloir que ces outils s'adaptent à la nouvelle syntaxe et aux dérives que cela peut entraîner, mais je ne pense pas que ce sera compliqué. J'imagine bien une règle qui interdit de mixer des arguments promouvants et des arguments standards dans un constructeur.

[Séb.]

Déçu par str_contains() et str_begins/ends_with() et leur gestion des chaînes vides incohérente avec l'historique.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
str_contains('foo', ''); // true
strpos('foo', ''); // false + warning

Je sens poindre les bugs.

[zozizozu]

Bon ben, j'ai essayé php8, c'est top
Interressant, vraiment typé, effectivement plus rapide ( je n'ai effectué que le "test de Mabdelbrot" cité dans l'article).
Bref tout ça m'a l'ait très bien, mais, ..., j'ai essayé avec les 3 outils php que j'utilise le plus souvent :
- Symfony => fatal error, absolument incompatible, par exemple la fonction PDOConnection::query() n'est pas compatible avec celle de la class héritée PDO::query( string $statement , int $fetch_style , ... )
- Prestashop => fatal error, absolument incompatible, par exemple "array_key_exists( $propertyName, $classObject)" ne passe pas du tout en php8, et c' est très bien.
- Wordpress => quelques warning et deprecated, sinon ça tourne nickel

J'ai tenté quelques correctif, mais il y a vraiment trop à faire.
Il semble que la compatibilité va être difficile à gérer, ..., sauf pour l'équipe de Wordpress ( souvent fustigé ici, c'est pourquoi je me permet de le souligner °)