Dates pour PHP 7 !

Hello,

De source officielle (compte twitter du release-manager de php7), la alpha 1 sort en début juin, pour une sortie en novembre

Etsi on discutait un peu de php 7 ?

Est-ce qu'il y a une page qui recense les principales nouveautés / les plus gros changements à venir par rapport aux derniers php 5.x ? J'ai beau fouiller sur php.net, je ne trouve pas grand chose.

En tout cas on dirait que sauter des numéros de version est à la mode en ce moment.

• scalar typihinting sur les paramètres
• le retour des fonction a du typehinting
• augmentation des perfs
• opérateur spaceshift
• débuggage
• le parenthésage est désormais 100% cohérent

etc.

Tiens c'est drôle ça. Python 3.5 (qui vient de rentrer en feature freeze / beta 1 et qui devrait lui sortir en septembre) rajoute lui aussi le type hint sur les fonction. Bon en pratique Python3 a déjà les annotation, la PEP ne vient que normaliser comment ils devraient être utilisés et l'interpréteur continuera à les ignorer. Mais la coïncidence est assez drôle.

• Infographie résumant les nouveautés de PHP7 ;
• Résumé de l'infographie.

Sinon, j'ai hate de voir les apports de performances, si c'est vraiment ce qu'ils nous vendent.

Tiens c'est drôle ça. Python 3.5 (qui vient de rentrer en feature freeze / beta 1 et qui devrait lui sortir en septembre) rajoute lui aussi le type hint sur les fonction

le typehinting existe depuis longtemps en php mais les types scalaire ainsi que le retour n'étaient pas fait.

le parenthésage est désormais 100% cohérent

Parfait. Est-ce que s'attaquer à la cohérence de la "lib standard" est prévu ?

le typehinting existe depuis longtemps en php mais les types scalaire ainsi que le retour n'étaient pas fait.

Tu entends quoi par type scalaire ? En gros qu'est ce qu'il était possible avant et avec php 7 ? Car là j'avoue avoir du mal à comprendre comment ils avaient put implémenter le type hinting a moitier.

Est-ce que s'attaquer à la cohérence de la "lib standard" est prévu ?

Nope. on parle quand même du Putain de Hack Pourri hein. Faut pas rêver.

Tu entends quoi par type scalaire ? En gros qu'est ce qu'il était possible avant et avec php 7 ? Car là j'avoue avoir du mal à comprendre comment ils avaient put implémenter le type hinting a moitier.

avant :

1
2
3
4

<?php
function maFonction($unStringMaisJePeuxPasVerifier, array $unTableauVerrifie, MaClasse $unObjetVerrifie){
    return "n'importe quoi";
}

PHPNG

1
2
3
4

<?php
function maFonction(string $unString, int $unInt, array $unTableau, MaClasse $unObjet):float{
    return 0.5;//ou 1 (int) ou "0.5" (string qui vaut 0.5 et peut donc être casté en float) sinon exception
}

les types scalaires sont int, float, string, bool cela n'était pas géré avant car ils sont silencieusement converti à chaque fois.

Si c'est correctement inspiré de Perl, un type scalaire est un type "atomique", comme les entiers, les références ou les chaînes de caractères, et ce sont ceux qu'on représente avec un sigil $.

Par contre pour moi la feature vraiment importante que je ne vois pas ici c'est la gestion de l'unicode. Cela dit, sur un langage typé à-la-Perl je vois mal comment on peut implémenter une gestion propre et explicite des encodages puisque justement tout est un scalaire.

Par contre pour moi la feature vraiment importante que je ne vois pas ici c'est la gestion de l'unicode. Cela dit, sur un langage typé à-la-Perl je vois mal comment on peut implémenter une gestion propre et explicite des encodages puisque justement tout est un scalaire.

l'unicode est utilisé par défaut depuis longtemps et il suffit d'utiliser mb_string pour faire des opérations sur de l'unicode. Aujourd'hui c'est par défaut pratiquement partout. C'est juste que le sysadmin doit l'installer lui meme pour que ça marche.

l'unicode est utilisé par défaut depuis longtemps et il suffit d'utiliser mb_string pour faire des opérations sur de l'unicode.

S'il faut utiliser un module particulier, alors ce n'est pas par défaut. Comment on différencie une chaîne encodée d'une chaîne unicode ? Ils ont des types différents ? Lequel est utilisé par défaut ? Les deux ?

Il n'existe que un type de chaine de charactères, c'est juste que les fonctions de base de manipulation de chaine ne supporte pas l'unicode. Un exemple (Habituellement, j'utilise codepad mais celui-ci ne supporte pas les fonctions mb_*).

https://wiki.php.net/rfc#php_70 grosso merdo

Grosso merdo, c'est voulu dans ce cas, pour "oublier" le fiasco de PHP6 qui a été avorté

Parfait. Est-ce que s'attaquer à la cohérence de la "lib standard" est prévu ?

La question a été abordée plusieurs fois (dont la dernière fois en mars dernier), mais ce n'est pas à l'ordre du jour… P.S : ceci est un argument de merde, vu que depuis quelques temps, la lib n'est pas si horrible que ça à utiliser (elle l'est quand même un peu incohérente, certes)

avant :

1
2
3
4
5
6
7
8
9

<?php
class Foo {
// ...
}

function foo(Foo $foo, array $hash, $str, $int, $float, $boolean) {
// les types décrits ici seront ceux passés à la fonction, sans vérif / conversion de type
var_dump($str, $int, $float, $bool);
}

1
2
3
4
5

// pour foo(new Foo, [], 4.0, 'str', 5, 'bool')
double(4)
string(3) "str"
int(5)
string(4) "bool"

en gros, fallait s'assurer que les bons types scalaires étaient passés avant de faire quoique ce soit (soit en transtypant via un $int = (int) $int; par exemple)

Après :

1
2
3
4
5
6
7
8
9

<?php
class Foo {
// ...
}

function foo(Foo $foo, array $hash, string $str, integer $int, float $float, boolean $bool) {
// quelque soit ce qui soit passé à la fonction, on aura forcément les types suivants :
var_dump($str, $int, $float, $bool);
}

Dans ce cas là, nos variables "scalaires" (int, string, bool, …) auront le bon type, convertit si besoin est (c'est là que le bat blesse, car il y avait une autre proposition concurrente, non adoptée, qui était plus exigente). En fait, par défaut, ça ne rale pas et convertit silencieusement, mais si on active le mode "strict" via declare(strict_types=1) en haut du fichier appelant les fonctions (pas déclarant les fonctions - du moins, ça ne fonctionnera pas et ne fera pas de vérif), là ça ralera si on passe en effet un string au lieu d'un int, etc.

Concernant l'unicode, hélas, ce fut une des raisons pourquoi php6 a été abandonné, car ce fut une galère à gérer, sachant, de mémoire, que ce fut l'utf16 qui avait alors été choisi…

Si tu veux détecter l'encodage, en ayant donc la fameuse extension activée (mbstring), tu pouvais alors faire un appel à mb_detect_encoding. Donc au moins, tu peux essayer de le détecter, mais c'est à toi d'y penser… Et en activant la dite extension, qui est maintenant activée par défaut, justement

Cool le troll sans fondement. C'est comme le chocolat : "PUTAIN C'EST DE LA MERDE MAIS * CRUNCH * JE MANGE * CRUNCH * QUAND MEME !". En gros. Noraj.

Cool le troll sans fondement. C'est comme le chocolat : "PUTAIN C'EST DE LA MERDE MAIS * CRUNCH * JE MANGE * CRUNCH * QUAND MEME !". En gros. Noraj.

heu, tout doux. oui c'est un troll, oui c'est assumé. Perso j'aime bien php, tout le monde ici le sait et il ne se passe pas un JZDS sans que je me fasse chambrer.

Bref, la lib standard de php ne sera sûrement pas changée avant la version 10 et encore, je suis gentil. l'historique de PHP est là dedans. Au départ Personal Home Page est une "glue" (en anglais dans le texte) entre le C et le HTML, c'est un hack.

PHP a subi de très belles évolutions, notamment avec la 5.3 puis la 5.4 (à mon humble avis la 5.3 a été la version pour "rattraper le retard" et la 5.4 pour faire de php un langage moderne). Depuis les choses avancent bien. Mais on ne peut nier l'historique.

Apres perso je comprend que la lib standard n'est pas non plus remise a plat car ça a un gros désavantage de le faire : ça va péter tous les codes. Or la large code base existante en PHP est clairement son meilleur atout. On voit bien que beaucoup des sites un peu à la modes / sortant des startup ne sont plus codés en PHP depuis quelques années (ou alors de façon minoritaire). Faire une release qui casse tout serait donc assez risqué pour l'ecosysteme PHP : c'est prendre le risque de devoir maintenir deux versions majeurs longtemps car les dev ne passeront pas instantanément et surtout prendre le risque que les dev se décident à changer de langage pour leur appli plutot que de mettre à jour complètement pour la nouvelle bibliothèque.

A mon avis les incohérences de la lib standard vous allez vous les coltiner encore un moment.

C'est justement pour ne pas se taper les emmerdes que Python se tape à cause de ça… Mais pour les startups, je suis pas sûr que PHP ne soit si peu utilisé. Surtout depuis PHP 5.3, qui, comme artragis l'a remarqué, a plus ou moins rattrapé un bon retard, et les versions suivantes (5.4, 5.5, …) ont aussi apportés des outils intéressants (certes existants déjà ailleurs). Bref.

Hélas, mais bon, on fait avec.

Sinon, en perfs, apparement c'est au coude à coude avec HHVM (qui est l'implémentation de PHP par Facebook), qui est deux à trois plus rapide que php 5.5 (qui pourtant était plus rapide que les précédentes versions…) :

• https://twitter.com/julienPauli/status/601422215322669056
• https://twitter.com/julienPauli/status/601422215322669056
• https://twitter.com/julienPauli/status/601420968641306624

Et enfin, un bon aperçu ici : http://fr.slideshare.net/jpauli/php7-is-coming

La passage a python 3 est long mais bon on parle d'une transition sur 10 ans et qui n'est pas qu'un changement de lib. Je fais partie de ceux qui pensent que python 3 est une bonne chose (et d'ailleurs je pense que la 3.5 va achever la 2.7 car les ajouts de cette version (sans compter ceux de la 3.4) vont en motiver plus d'un).

Concernant PHP, c'est vrai que quand je dis qu'il est moins utilisé pour de nouveaux projets, je le sort du chapeau. Mais j'ai pas l'impression qu'il y a des tonnes de mouvements dans l'écosystème PHP. Après c'est peut etre qu'une impression. PHP reste et restera encore un moment, rien que par la large part de sites qui existent aujourd'hui. Mais en 2015 je dois avouer que j'ai du mal a voir sous quel condition je l'utiliserai ou meme conseillerai PHP a un débutant

J'aimerais juste signaler à ce sujet qu'il est possible de faire en sorte que les fonctions "courantes" sur les chaînes de caractères prennent en compte l'unicode moyennant un paramétrage. Derrière, si j'ai bien compris la doc', PHP fait simplement appel aux fonctions mb_* correspondantes, ceci probablement en attendant que le support du jeu de caractères soit réel/complet/correct/etc..

l'unicode est utilisé par défaut depuis longtemps et il suffit d'utiliser mb_string pour faire des opérations sur de l'unicode.

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.

ON risque donc d'avoir encore un bon moment à faire avec des bugs d'encodage à la con parce qu'un bout attend de l'UTF-8 et l'autre de l'ISO-8859.

Dommage, vraiment.

J'aimerais juste signaler à ce sujet qu'il est possible de faire en sorte que les fonctions "courantes" sur les chaînes de caractères prennent en compte l'unicode moyennant un paramétrage. Derrière, si j'ai bien compris la doc', PHP fait simplement appel aux fonctions mb_* correspondantes, ceci probablement en attendant que le support du jeu de caractères soit réel/complet/correct/etc..

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

Je félicite python 3 pour avoir choisi un système très bien conçu à ce niveau: d'un côté on a les chaînes binaires, et de l'autre les chaînes de caractères, la distinction est claire entre les deux et pour passer de l'un à l'autre on est obligé d'indiquer dans l'encodage dans lequel on travaille, ce qui empêche toute erreur.

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 ?

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.

Et pour les performances, j'attends de voir comment ça tourne sur un site complet, les benchmarks se laissent écrire. LE simple fait de dire que ça va se situer entre 25% et 70% en dit long, ça veut tout et rien dire.

Du coup au final s'il n'y a que ça, c'est somme toute assez pauvre pour une version majeure.

C'est justement pour ne pas se taper les emmerdes que Python se tape à cause de ça…

Les difficultés du cassage de la rétrocompat de Python 3 ont été anticipées, prévues et planifiées sur 10 ans, et on arrive aujourd'hui quasiment au bout de la période de transition. Et qu'est-ce qu'on en tire ? Le constat est simple : la base d'utilisateurs de Python et son écosystème n'ont fait qu'augmenter ces 10 dernières années. Il ne reste plus que quelques technos particulières qui résistent toujours au changement, comme scapy… dont il existe cependant un fork en Python 3 en cours de développement.

Du coup j'aimerais bien savoir ce que tu appelles "les emmerdes que Python se tape à cause de ça".