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!

[Alexandre T]

De rien ! Ce merci fait plaisir !

[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.

[Dendrite]

Tu m'étonnes.
Je réagis comme toi et pense que c'est contre-intuitif.
Mais mon mari matheux trouve ça normal.

[grunk]

On va quand même pas commencer a avoir des comportements cohérents entre des fonctions d'une même famille 🤣

[Alexandre T]

Bonjour,

Oui, je sens aussi les bugs poindre. Ce qui m'agace aussi, c'est de ne pas uniformiser le nom des fonctions. Le tiret bas est depuis la version 5, le caractère séparateur entre les mots des noms de fonction, mais aucun alias n'a encore été créé pour strpos. C'est donc peu probable que cette fonction sera dépréciée en version 8. Sinon, je partage le point de vue du mari de Dendrite, les deux résultats sont corrects et tout autre résultat serait à mon sens anormal.

[Dendrite]

Et les haystacks et needles (sur toutes les fonctions) sont-ils enfin tous dans le même ordre depuis une certaine version ? Question de néophyte.

[zozizozu]

Si j'ai bien compris, les attributs type ORM n'ont pas besoin d'être dans un commentaire, on va pouvoir désactiver opcache.save_comments, youhou !!!

[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 °)

[CosmoKnacki]

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.

On ne peut pas vraiment le reprocher, car le fait que strpos('foo', '') renvoie false avec un warning en plus est une aberration: la chaîne vide est présente à chaque position d'une chaîne. D'ailleurs dans les versions 8.0 alpha 1-2-3, ce comportement a été corrigé et strpos renvoie donc 0, ce qui du coup est au diapason avec les fonctions str_(contains|starts_with|ends_with).

[Séb.]

Qui cherche une chaîne vide ? Personne.
Existe-t-il une utilité quelconque à ce comportement ?
Je ne vois que des effets de bord.

Pour moi, c'est comme dire que 0 est présent dans chaque addition 123 = 123 + 0, et que donc 123 == 0

[CosmoKnacki]

Qui cherche une chaîne vide ?

Toi au post #10.

Existe-t-il une utilité quelconque à ce comportement ?

La première utilité est la cohérence avec les autres fonctions, et dans l'absolue, le sens: renvoyer false ne veut rien dire, il ne s'agit pas d'une sous-chaîne absente. Après pour ce qui est de l'exploitation qu'on pourrait faire de ce résultat, il ne faut présumer de rien et le garder dans un coin de sa tête au cas où.

c'est comme dire que 0 est présent dans chaque addition 123 = 123 + 0

L'image est intéressante pour str_contains et cie: 0 est bien présent dans chaque nombre du point de vue de l'addition, dit autrement, 0 ne change pas le nombre auquel on l'additionne (c'est d'ailleurs grâce à cette propriété tellement évidente qu'on l'oublie qu'on peut résoudre un équation du type x + 10 = 15 en faisant apparaître 10 - 10 à droite). Pourtant à qui viendrait l'idée tordue d'interdire d'ajouter ou de retrancher 0 (de dire qu'il n'est pas là) sous prétexte qu'il ne change rien?

On peut faire le même type de parallèle entre strpos et la multiplication par 0: la chaîne vide est l'élément absorbant de l'opérateur strpos puisque quelque soit la chaîne elle renverra le même résultat.

La comparaison s'arrête là car dans les deux cas les "valeurs" renvoyées n'appartiennent pas aux mêmes ensembles que celui des opérandes. Malgré cela, je vois mal l'utilisation d'un quelconque langage qui balancerait des false assortis ou pas de warnings à chaque tentative d'addition ou de multiplication avec 0 si ce n'est au club informatique de Ste Anne.

Plus sérieusement, PHP est un langage qui traînent des incohérences à tous les niveaux du fait notamment qu'il a connu une adoption massive alors que c'était un langage encore jeune et qu'il a misé sur la retro-compatibilité, ce qui fait qu'elles perdurent. Mais si tu regardes les autres langages (Python, Javascript, Ruby...), tu verras que ces valeurs qui t'étonnes sont belles et biens les valeurs renvoyées pour leurs fonctions ou méthodes équivalentes.

et que donc 123 == 0

Tu es possédé par Belzébuth, il te faut le secours des pères Merrin et Karras.

[Séb.]

Qui cherche une chaîne vide ?

Toi au post #10.

Voilà, permettre un comportement en tout point inutile qui retournera toujours un succès quelque soit le $haystack ne sert à rien, si ce n'est créer de la confusion et des bugs.