Dates pour PHP 7 !

Bizarre, j'ai mis en prod récemment un Prestashop et il tourne depuis l'été dernier sur différents serveurs de développement avec du PHP 5.5 et 5.6 sans problème…

Vous auriez pas une version de derrière les fagots ou un plugin à la traine ?

+1 pour les hébergeurs, OVH travaille beaucoup comme ça. Je sais pas comment ça va se passer sur mon dédié : est-ce que le apt-get upgrade va forcer le passage à PHP 7 ou ça restera sur PHP 5.x ?

PHP 5.5, ça passait, mais pas 5.6 pour le site qui nous posait problème (problème dans l'utilisation d'une méthode de hachage sans padding pour la clé, si je me souviens bien). Après, je n'ai plus le numéro de version de Prestashop en tête, et je n'ai pas re-testé avec la 1.6.0.14 sur PHP 5.6, mais si tu dis que ça fonctionne, c'est que ce n'était manifestement pas la dernière 

Ce serait intéressant de savoir comment ça s'est passé quand PHP 5 est arrivé. A mon avis, il y a des risques que ce soit PHP 7 qui s'installe.

Je sais pas comment ça va se passer sur mon dédié : est-ce que le apt-get upgrade va forcer le passage à PHP 7 ou ça restera sur PHP 5.x ?

apt-get upgrade donc tu es sur Debian ou dérivée. Donc tant que tu n'est pas sur une dérivée en rolling release (mis à part Debian Sid je ne sais pas s'il y en a), apt-get upgrade te garantit que tu reste sur la même version mineure et que tout ce que tu vas récupérer c'est des mises à jour de sécurité.

Pour avoir un comportement différent (donc monter de version), il faut activer des mécanismes spéciaux comme les backports ou mettre à niveau toute la distribution (ce qui ne se fait pas par mégarde).

PS : C'est le cas pour tous les paquets, pas seulement PHP.

Quand j'y pense, je me dis qu'à l'installation ça donne apt-get install php5, pas php. Donc peut-être aura-t-on droit à php7… Peut-être même en parallèle pour tester (si c'est le cas, bonjour la config Apache) ?

Le renard confirme, visiblement

Je vais même plus loin : tu ne pourras pas avoir PHP7 dans les paquets tant que la distribution ne les aura pas intégrés. Et tu devras activer les backports si tu ne veux/peux pas mettre à jour la distribution une fois ceux-ci intégrés.

Quelqu'un sait si le support des fonctions mysql_ va se terminer sur la 7 ? Sur le site, ils disent que c'est "très prochainement", mais à l'échelle d'un langage, ça veut pas dire grand chose.

Si c'est le cas, je connais un paquet de développeurs qui vont se payer un bon refactoring !

C'est pas comme si personne na'vait jamais prévenu. Ca doit bien faire 8 ou 10 ans que mysql_* est fortement déconseillé et que PDO, ou au minimum mysqli, sont recommandés partout.

Pareil pour ceux qui utilisent encore ereg_ à la place de preg_.

Ceci dit, on voit encore toujours des topics de désespoir alors effectivement, il y en a qui vont bien s'amuser. Quand je pense que je connais encore quelques sites qui tournent avec… php 3, ça me donne des frissons.

Et dans un autre registre, petite pensée spéciale pour ceux qui utilisent encore l'agonisant Visual basic 6; ou Java 1.4; il y en a encore !

Le problème, c'est que plein d'auteurs de tutoriels sur le net n'ont pas fait le pas de mettre à jour leurs tutos de mysql vers PDO.

http://openclassrooms.com/courses/un-livre-d-or
http://openclassrooms.com/courses/des-news-sur-votre-site
…

le problème c'est qu'OC se base sur une mine de cours non mise à jour et quand les tutos sont à jour, ce sont les PDF (même payants) qui ne le sont pas. Ils le savent mais c'est pas prioritaire, surtout que la mise en ligne est de la charge de l'équipe technique.

Même developpez.com essaie de plus en plus de réduire la visibilité des vieux trucs ou de les mettre à jour.

Je ne parle pas bien évidemment des blogs qui de toute façon obéissent au diktat de google : plus c'est vieux moins ça a de chance d'être en haut des résultats.

A nous de créer un tutoriel pour les y aider (je l'ai déjà proposé dans le sujet ad hoc)

Sinon, je pense que je vais voir pour m'installer PHP 7 avec mon WAMP, juste pour m'amuser un peu.

Pour la valeur pédagogique, on pourrait effectivement écrire un tutoriel sur la création d'un livre d'or et d'un blog.

Par contre, les livres d'or sont vraiment has been aujourd'hui, et pour les blogs, y'a WordPress

Par contre, les livres d'or sont vraiment has been aujourd'hui, et pour les blogs, y'a WordPress

Complètement d'accord pour les livres d'or, mais pour les blogs ça dépend: c'est quand même vachement plus intéressant pour son apprentissage personnel de coder soi-même que d'installer un truc qui fait tout tout seul.

IL n'en reste pas moins qu'effectivement, le fond de la pensée est juste, écrire un tutoriel c'est une chose, mais le maintenir à jour en est une autre; surtout que là on parle d'une maintenance sur plusieurs années.

C'est ce qui me fait dire finalement que, comme l'a déjà dit je ne sais plus qui sur la page 1, php est et va globalement continuer sur la pente descendante.

En fait, je pense que php 7 va faire un flop. En soi hormis l'amélioration drastique des performances (ce qui reste encore à prouver), il n'y a pas vraiment de nouveauté choc. En fait ils ont déjà grillé les cartouches avec php 5.3, 5.4 pui 5.5. Pour moi c'est l'une de ces trois versions qui aurait dû s'appeler php 7. Là comme il est actuellement présenté, il se serait appelé php 5.7 que ça aurait été pareil.

Après autant d'attente et un php 6 raté, en annonçAnt php 7, on devrait s'attendre à un changement significatif à mon avis.

. En soi hormis l'amélioration drastique des performances (ce qui reste encore à prouver)

heu, les "bench" qui ont été fait l'ont été sur du wordpress, prestashop etc. pas sur "la fractale de menderbrot" ou "calculer les 10000 premiers nombres premiers". La preuve est là.

Par contre ça me fait peur car jusque là les gars de FB avaient dit "La seule manière d'améliorer les perfs de PHP de manière satisfaisante c'est de faire du JIT" du coup HHVM ne se base presque que sur ça.

Chez ZEND, ils ont mis très exactement 0 élément de JIT dans leur phpng et ils arrivent à avoir une VM qui tourne aussi vite que HHVM. J'ai du mal là. Soit c'est FB qui fait de la merde et du coup la montée en force de HHVM est une mauvaise chose, soit c'est Zend qui dit nimps.

Ensuite, pour les fonctionnalités. Oui php 5.3 a eu toute l'internationalisation ainsi qu'un vrai module d'objet. Oui php 5.4 a eu les traits les ImmutableDateTime, des améliorations de la SPL etc. Oui la 5.5 a eu les générateurs.

Mais php7 supprime:

• TOUTES les fonctions obsolètes, pas quelques unes, pas un ou deux héritages style registerglobals, non TOUTES les fonctions obsolètes,
• TOUTES les fuites de mémoires sont colmatées
• les performances sont largement améliorées alors que le travail sur le JIT bien que globalement souhaité par la communauté n'a pas encore commencé
• phpng se base sur un arbre syntaxique (proposé par un français cocorico!),
• les closures ont été améliorées et le binding peut être enfin utilisé partout, même hors des objets,
• les typehint permettent de développer des libs plus fiables,
• les CATCHABLE_ERROR seront plus facilement attrapables,
• le langage est enfin cohérent (/!\ langage != lib standard) et prévisible dans le parenthésage, l'exécution des constructeurs etc.
• les classe anonymes

tu as le droit d'avoir ton avis, mais même si on n'est plus au niveau du "rutilent" les changements sont profonds dans le coeur du langage mais aussi de sa communauté, passer à une version majeure est plus que nécessaire.

phpng se base sur un arbre syntaxique

Oo … Heu… Il utilise quoi PHP 5 ?

edit: j'ai ma réponse, le parseur produisait directement le bytecode

Arrêtez-moi si je dis une bêtise, mais je crois qu'il analyse à la volée (un peu comme les parseurs SAX, tandis qu'un arbre syntaxique correspondrait à un parseur DOM, je dirais)

Bon, je n'y connais pas assez, mais il faut quand-même analyser pour avoir le bytecode, non ? 

Bon, je n'y connais pas assez, mais il faut quand-même analyser pour avoir le bytecode, non ?

oui mais ZE2 était un parseur séquentiel à une passe. Pour faire un AST il faut deux passes mais cela rend les choses plus simples à utiliser d'une part mais aussi à optimiser pour éviter les répétitions inutiles de bytecode. C'est Iven Enderling, le créateur de Hoa et chercher à Inria qui a fait la proposition sur @internals (il jouait à ce jeu pour Hoa\parser) et Zend a implémenté le truc dans phpng suite à la formalisation dans la RFC que j'ai présentée.

Je trouve ça quand même fou qu'un langage puisse vivre et être déployé dans le monde entier pendant 5 versions majeures sans être compilé en AST pendant son parsing. Je voudrais pas être à la place des gens qui ont maintenu le compilateur pendant toutes ces années.

Du coup je comprend mieux les gains de perfs et les précédentes erreurs de parenthesage.

Ah, intéressante l'info sur le parsing.

Ca explique mieux pourquoi des instructions à première vue totalement anodines genre $foo[0]->bar ou new Foo() ->bar(); provoquent ou provoquaient des parse errors complètement absurdes et sans fondement, alors que la même chose sur deux lignes ou des variables temporaires fonctionnaient très bien.

Par contre ça me fait peur car jusque là les gars de FB avaient dit "La seule manière d'améliorer les perfs de PHP de manière satisfaisante c'est de faire du JIT" du coup HHVM ne se base presque que sur ça.

Ca fait quand même déjà quelques années qu'ils ont dit ça il me semble. C'est à prendre à mon avis dans le sens « à l'époque c'était la seule manière évidente d'améliorer les performances de manière satisfaisante ».

Mais php7 supprime: TOUTES les fonctions obsolètes, pas quelques unes, pas un ou deux héritages style registerglobals, non TOUTES les fonctions obsolètes,

Certes. Mais les éléments supprimés ne font jamais de buzz. C'est pour ça que d'après moi, ils ont déjà grillé les principales nouveautés. C'est pas grave hein, ils ont juste perdu des occasions de réveiller un peu les gens qui ont abandonné php, qui sont passés à autre chose et qui pourraient revenir.

Au fait, est-ce qu'il y a une liste quelque part, des fonctions obsolètes qui vont disparaître de php 7 ?

Tiens.

Merci pour le lien.

Je souhaite juste revenir sur le JIT ; en fait, phpng a été conçu certes pour améliorer les perfs, mais surtout rendre plus facile l'intégration d'un compilo JIT justement (source : https://wiki.php.net/rfc/phpng#impact_on_a_future_jit_implementation)

Oh et BTW, Nikita Popov (Nikic, le type qui proposé et fait l'AST) est un allemand, pas un français.