Dates pour PHP 7 !

Ah mais ne te méprend pas, je trouve aussi que Python 3 est une très bonne chose (comme tout nouvelle version de langage / lib / etc). C'est juste que devoir maintenir pendant pas mal de temps une version majeure dépréciée était ce que voulait éviter les core dev de PHP (c'est ce que j'appelle les "emmerdements"), pour pouvoir se concentrer sur une seule version. D'où le lancement de dépréciations, nettoyages de trucs déprécies en php 7, puis le débarras de celles-ci dans php 8 (prévue pour 2020 apparement).

Bah au vu de l'ecosysteme php (je ne peux pas parler en matière de startups de façon globale, mais sur les deux trois (dont celle où je bosse), on est assez friands des avancées de php (parce que notre app était en php à l'origine, certes). Et je pense que c'est un peu la même chose avec tout l'ecosysteme qui se développe autour (Symfony, les outils tels Composer, Behat, …).

Je voulais aussi revenir sur l'unicode : bien que php7 ne le supporte pas nativement, il pourra au moins comprendre les codes unicodes sous la forme \u{code} (par exemple \u{262F], au lieu d'être affiché \u{262F} sera affiché par ☯ à place.

Bref. Pourrait-on s'il vous plaît recadrer le sujet pour qu'on puisse discuter des avancées proposées par PHP7, plutôt que d'un éternel débat qui tourne en rond ? Merci

Du coup, supporté, oui et non en fait. Si tu as une chaîne quelconque dans une variable, tu n'as pas de moyen simple et immédiat ni pour savoir dans quel encodage elle est, ni pour la convertir si nécessaire.

bah si, mb_detect_encoding, mb_convert etc.

Ca reste un patch pourri digne de REGISTER_GLOBALS, c'est pas une très bonne approche.

ça n'a juste rien à voir. En php 5.3 le paramétrage doit être explicite, en 5.4 c'est par défaut utf-8 tout comme les strings py3 sont par défaut utf8. Et si ça semble tout simplifier sur py3 il suffit qu'à un moment tu aies besoin (j'entends par là c'est un vrai besoin applicatif) de passer par des bytes, tu te retrouves avec des bugs bien foireux, pourtant c'est python3. Avec php c'est pareil.

IL est casté silencieusement, une exception ou une erreur se produit

Comme je le disais, on est en php, par défaut on ne joue pas avec des exception mais des erreurs, c'est donc une CATCHABLE_FATAL_ERROR qui est levée, il faut ensuite définir un handler pour que ça marche.

/!\ ceci vaut pour les typehint d'objets ou de tableaux, ou bien quand le typage est défini à "strict" sinon, le parseur va avant tenter de faire une conversion implicite dans le cas des string, float, int, bool

JE ne vois pas trop non plus l'utilité d'ajouter un opérateur spécial pour les comparaisons à la strcmp. C'est quand même ultra-spécifique. A voir à l'usage.

de manière très simple, ça permet de définir une closure en une ligne pour faire des tris. donné que les utilisations habituels de php c'est 30% gérer des strings, 30% gérer des tableaux et 30% d'attente de la bdd c'est plus qu'utile. Pour les 10% restant, c'est pas un oubli, c'est juste que ça dépend du site.

BTW, en PHP7, on aura (enfin !) des exceptions catchable à la place des erreurs classiques. Enfin, du moins au moins pour les erreurs de syntaxe ou autres genres (je ne sais plus trop lesquelles), un peu à la python (faut le reconnaître).

Merci pour la liste de nouveautés et les exemples de type hinting, je ne comprenais pas ce terme sans les exemples. Mais du coup, question: qu'est-ce qui se passe si on passe un paramètre dans le mauvais type ? IL est casté silencieusement, une exception ou une erreur se produit, ou bien il ne se passe rien parce que ces indications sont supprimées à l'analyse et donc on part du principe qu'elles ne sont que des aides pour les humains ?

Pour reprendre ce que je disais sur le TH, ça dépend si tu as le mode strict ou non. Si tu as le mode strict, si c'est le mauvais type, ça ralera cash et fera planter ton script (sauf si tu catches l'exception dont je parle dans ce même message). Si tu ne l'active pas, une conversion silencieuse est tentée.

J'avais une question à propos de PHP et de ses évolutions, c'est sans doute le bon endroit pour la poser.

Est-ce-que dans le futur, il est prévu de fournir du sucre syntaxique, ou un truc plus élégant que des function pour ce genre de trucs donc l'implémentation du pattern Reactor made in nodejs (ou équivalents) ?

J'imagine qu'en python l'approche plus ou moins fonctionnelle du langage a pu permettre ce genre de trucs.

Java a finalement reçu ses lambdas avec Java 8… Ce qui a grandement favorisé son utilisation dans des frameworks "event-driven".

Javascript est sur la voie aussi avec les arrow functions.

Y a-t-il quelque chose dans les cartons pour PHP ? Ou ça existe déjà ptet' ? (mais le framework que j'ai pris en exemple ne s'en sert pas ?)

@Javier : Je suis pas surs de comprendre. Le pattern Reactor me fait penser à la programmation asynchrone tandis que les arrow functions ne semblent être que des lambda.

[HS Python]Concernant Python, on a les lambda. Pour la programmation asynchrone, outre les packages dédiés existant (twisted, tornado, etc.), le module asyncio de la lib standard est arrivé avec python 3.4 pour standardiser la gestion des boucles événementielles et Python 3.5 va voir arrivé deux nouveaux mots clés (async et await) pour intégrer la notion de coroutines et d'evenements asynchrones directement comme des constructions du langages (et non comme des formes particulière de générateur comme précédement.[/HS]

En gros quand t'essaies d'implémenter le pattern reactor (tout à fait c'est de la programmation asynchrone avec une event-loop et tout et tout) et que t'essaies de fournir une API pour construire des applis web, tu vas avoir besoin de "callbacks" du style "quand une requête arrive, traite là de telle façon".

Si tu regardes avec Javascript ES5, tu vas "modéliser" ça par des fonctions (anonymes ?) du style :

1
2
3
4

var server = http.createServer(function (request, response) {
  response.writeHead(200, {"Content-Type": "text/plain"});
  response.end("Hello World\n");
});

Le premier paramètre de createServer est une fonction. Avec l'arrivée des arrow functions, c'est moins vilain.

Pire, en Java c'était complètement ingérable avant l'arrivée des lambdas :

1
2
3
4
5

server.requestHandler(new Handler<HttpServerRequest>() {
    public void handle(HttpServerRequest req) {
        req.response().end("Hello, world");
    }
);

(fallait passer par une classe anonyme, infernal…)

Et maintenant :

1
2
3

server.requestHandler(req -> {
    req.response().end("Hello, world");
});

En gros les frameworks asynchrones, basés sur de l'event-driven tire énormément partie des lambdas (ou des arrow ou des closures ou de peu importe comment on l'appelle) en termes de lisibilité des APIs. Et je me demandais où PHP se positionnait sur le sujet.

C'est plus clair ?

l'asynchrone n'existe sous aucune forme en php afaik.

Mmh, je peux parfaitement me tromper (my bad dans ce cas) mais le lien que j'ai cité plus haut : https://github.com/reactphp/react ressemble beaucoup à une telle implémentation.

Et du coup c'est un peu pour ce genre de frameworks/libs que je me pose la question. Plus le langage permet d'avoir des trucs corrects et élégants, plus t'as de chances que des gens utilisent le framework en question.

L'asynchrone, pas sûr que ça soit si important que ça en php. La grosse différence avec un serveur d'apps java ou nodes c'est que l'application ne tourne pas en permanence en arrière-plan.

Exécuter une application en arrière-plan, on peut le faire aussi en php mais c'est vraiment pas courant il me semble; on table toujours sur un apache derrière, et une requête HTTP = un script php exécuté, et rien ne reste en mémoire après / entre les requêtes. A moins que ça ait changé avec php 7 mais j'en doute.

Exécuter une application en arrière-plan, on peut le faire aussi en php mais c'est vraiment pas courant il me semble; on table toujours sur un apache derrière, et une requête HTTP = un script php exécuté, et rien ne reste en mémoire après / entre les requêtes. A moins que ça ait changé avec php 7 mais j'en doute.

sauf que l'asynchronisme peut se faire ailleurs, n'oublions pas que php est aussi un langage de script.

N'oublions pas que pas mal de choses se font via API aujourd'hui et quand on doit (même ponctuellement) aller faire un certains nombres de requêtes que ça soit vers des API REST, des bdd NoSQL style couchDB ou même vers un sgbd plus classique avant de tout traiter, faire de l'asynchrone peut être très sympa (idem pour l'insersion) car cela permet de paralléliser d'une part mais surtout de mettre en pause l'exécution de la page le temps que les choses se passent. Pareil pour les envois de mails.

En fait QuentinC on pourrait dire pareil de Java : pas sûr que ce soit intéressant d'aller fouiller du côté de l'asynchrone quand la pile Java EE existe et permet de faire tout plein de choses.

Le truc c'est que ça ne remplit pas les mêmes rôles.

En complément de ce qu'a dit artragis, ce genre de frameworks permettent de tirer très fortement partie d'un minimum de threads, et c'est vraiment, vraiment pas négligeable. La "machinerie" classique consistant à dédier un thread au traitement d'une et une seule requête et d'avoir un pool de threads à disposition, jusqu'à ce qu'on en ait plus, et qu'on opte pour une machine plus puissante.

L'idée des frameworks asynchrones c'est que la plupart des traitements associés à une requête (essentiellement dans le cas d'une API web) sont généralement courts et même s'ils sont longs (un round-trip réseau pour aller chercher des données sur une base distante, etc.) ils ne devraient pas être bloquants (c'est typiquement le cas de l'exemple ci-dessus : pourquoi bloquer un thread alors qu'on attend des données qui traversent le réseau ?) du coup l'asynchrone permet cela : on utilise un minimum de threads et on rend la main dès qu'on peut. L'event-loop s'occupe d'ordonnancer tout ce petit monde.

Après le langage dans tout cela, c'est plus une question d'habitude. Si les gens sont habitués à développer en PHP, je trouve que c'est une bonne idée qu'eux-aussi puisse bénéficier d'un framework asynchrone pour de petites API simples, pour utiliser des websockets, … Evidemment, quand t'as une page complexe, avec un rendu côté serveur assez important, qui implique d'utiliser des transactions sur une BDD (là pour le coup c'est bloquant), le modèle 1 thread 1 requête reste le plus adapté, c'est clair.

L'asynchrone (tel qu'on l'entend aujourd'hui), c'est un peu le retour aux sources du multitâche après avoir constaté les limites des threads. Vu que PHP n'est pas orienté système je ne suis pas plus surpris que ça qu'il ne s'agisse pas d'un sujet chaud pour ce langage, alors que le potentiel que ça représente en Python en termes de performances pour des applis réseau est gigantesque.

PS : pas seulement pour le web d'ailleurs. Le simple fait de décider explicitement quand, précisément, une tâche doit laisser la main aux autres permet de créer des programmes concurrents qui sont prévisibles et plus faciles à optimiser/scaler. A contrario les threads peuvent être suspendus à plus ou moins n'importe quel moment lors d'un appel système, ce qui impose des locks et des mecanismes parfois gourmands pour s' assurer que tout ce petit monde ne va pas chier sur la pelouse du voisin.

TL;DR : threads are hard and heavy, asynchronous IO are predictible and fun.

L'asynchrone (tel qu'on l'entend aujourd'hui), c'est un peu le retour aux sources du multitâche après avoir constaté les limites des threads. Vu que PHP n'est pas orienté système je ne suis pas plus surpris que ça qu'il ne s'agisse pas d'un sujet chaud pour ce langage, alors que le potentiel que ça représente en Python en termes de performances pour des applis réseau est gigantesque.

En python, c'est aussi vachement plus critique d'avoir ces possibilités à cause du GIL non ?

Pour afficher une page web classique je ne vois pas trop à quoi ça sert en fait: on a besoin d'avoir toutes les données en retour de la base / de l'API HTTP(S) distante quoi qu'il arrive pour générer le HTML et/Ou le js, donc on ne peut en aucun cas rendre la main plus tôt; la page ne s'affichera donc au final pas plus vite dans le browser de toute façon.

Ou alors j'ai rien pigé au concept.

Côté serveur on a par contre tout intérêt à diminuer le nombre de threads, d'où select et asyncio… mais ça ne s'utilise pas dans le même contexte.

donc on ne peut en aucun cas rendre la main plus tôt; la page ne s'affichera donc au final pas plus vite dans le browser de toute façon.

• quand tu parallélises tu est forcément plus rapide
• les protocoles réseaux sont asynchrones par conception (du moins IP est asynchrone, contrairement à MINITEL), il te suffit de créer un "never ending frame" pour que de nouvelles données s'affichent au fur et à mesure et là tu utilises à plain l'asynchrone

Non pas forcément. En fait le GIL est un faux problème.

• Il contraint juste tout le code pur Python à être exécuté séquentiellement, mais il est tout à fait possible de faire des pointes à 150% de CPU ou plus sur un soft en Python (c'est mon grand jeu au boulot en ce moment…), parce que beaucoup de code en Python fait appel à des bibliothèques natives qui n'ont pas besoin d'avoir la main sur le GIL pour s'exécuter. En particulier, Cython propose un context manager with nogil: qui permet de dire "le code suivant sera traduit en natif pur, donc il est parallélisable et peut être exécuté sur un coeur séparé pendant que tu fais bosser un autre thread".
• Les coroutines (enfin, asyncio, quoi) assument pleinement cette contrainte (mono-coeur) et n'ont aucun problème de GIL : ça revient en fait strictement au même que faire des threads dans du code Python pur, avec beaucoup d'appels système en moins, sans risque de race conditions, et en sachant exactement quand vont avoir lieu les permutations entre codes concurrents.

Pour afficher une page web classique je ne vois pas trop à quoi ça sert en fait: on a besoin d'avoir toutes les données en retour de la base / de l'API HTTP(S) distante quoi qu'il arrive pour générer le HTML et/Ou le js, donc on ne peut en aucun cas rendre la main plus tôt; la page ne s'affichera donc au final pas plus vite dans le browser de toute façon.

Ça dépend : on peut imaginer faire tous les appels (base/API) simultanément et construire les données de la page de retour au fur et à mesure que les réponses arrivent avant de faire le render final. Les appels pour récupérer les données sont typiquement parallélisables avec des IO asynchrones puisque quand on attend une réponse, le processus s'endort.

Côté serveur on a par contre tout intérêt à diminuer le nombre de threads, d'où select et asyncio… mais ça ne s'utilise pas dans le même contexte.

Je n'irais pas jusqu'à dire qu'on a tout intérêt à diminuer le nombre de threads : si le serveur a à sa disposition N coeurs, alors tu peux imaginer lancer N-1 instances de ton serveur asyncio (et garder un coeur pour le serveur du SGBD par exemple) pour répartir la charge et occuper équitablement les ressources en calcul de la machine…

C'est juste une façon différente (et plus facile à scaler, et sur laquelle il est plus facile de raisonner) de concevoir un serveur.

Pas forcément : les perfs font une cloche en fonction du nombre de threads utilisés et de coeurs dispos sur la machine.

• les protocoles réseaux sont asynchrones par conception (du moins IP est asynchrone, contrairement à MINITEL), il te suffit de créer un "never ending frame" pour que de nouvelles données s'affichent au fur et à mesure et là tu utilises à plain l'asynchrone

Je suis pas sûr de voir où tu veux en venir. Ce qui est asynchrone, c'est l'échange, qui permet de se dire en gros "je fais autre chose (je traite une autre conversation) en attendant que celui-ci me réponde".

Dans tous les cas, pour terminer ce HS : j'ai actuellement un article en préparation sur le sujet (le retour des coroutines) sur ce sujet précisément, donc je propose qu'on arrête de pourrir ce thread avec une digression sur une feature que PHP 7 n'inclura pas et qu'on la reprenne ailleurs à ce moment-là.

L'intérêt de la programmation asynchrone est assez évident, surtout pour le web ou tu passe 90% du temps a attendre les io (disque ou db). Une boucle asynchrone permet alors d'occuper le thread a ce moment la.

Ensuite pour le gil c'est un faux problème pour 90% des utilisateurs de python je pense. Nohar a expliqué qu'il est déjà possible d'en passer outre. CPython n'est pas la seule implémentation bloqué sur un coeur : ruby ou node.js ont la meme contrainte (et node est meme mono thread). Et on en entend moins parler.

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 !

Quelqu'un sait si le support des fonctions mysql_ va se terminer sur la 7 ?

Oui, toutes les fonctions qui lançaient un avertissement deprecated sont enlevées de php7.

J'en connais qui vont avoir mal !

Déjà que je tombe parfois sur des mecs qui désactivent toutes les erreurs pour ne pas avoir à déboguer (bah oui, vérifier qu'une variable existe avant de l'utiliser c'est dur, idem pour remplacer les fonctions mysql_* par PDo ou autre)…

Je sens que beaucoup vont se prendre la tête quand les hébergeurs feront des mises à jour forcées

Est-ce-que ça ne va pas "refroidir" les hébergeurs du coup ? (question naïve mais c'est un environnement que je ne connais pas bien).

Disons que, comme lors de la sortie de PHP 5.3 et 5.4, ils vont simplement proposer pendant un moment plusieurs versions en parallèle, mais les anciennes ne resteront pas longtemps.

Au boulot, on utilise un hébergeur qui propose encore PHP 5.2, juste parce que Prestashop recommande encore cette version, malgré le fait que (et je n'ai pas encore testé) la dernière version mineure supporte enfin correctement PHP 5.6. Auparavant, on ne pouvait tout simplement pas accéder à l'administration du site.

M'enfin, c'est dommage de proposer plusieurs versions (notamment cette vieille 5.2). Forcer à mettre à jour ça nous (me ?) ferait du boulot