Sortie de PHP 5.6

Posté par _jordan_ le 09 septembre 2014 à 10:18. Édité par palm123, Stéphane ESCAICH, Benoît Sibaud et cfx. Modéré par Ontologia. Licence CC By‑SA.

Étiquettes :

sept.

2014

Ultime version de la branche 5.x, PHP 5.6.0 apporte quelques possibilités de développement, un débogueur interactif et corrige quelques 150 bogues.

Les principales nouveautés sont :

Les expressions de constantes scalaires
Fonctions à nombre d'arguments variable ainsi que l'opérateur ... pour empaqueter/dés-empaqueter les arguments
L'opérateur ** pour l'exponentiation
L'extension du mot-clé use pour importer les fonctions et les constantes
Un débogueur interactif : phpdbg intégré comme module SAPI.
La ré-utilisabilité de php://input faisant passer $HTTP_RAW_POST_DATA en déprécié.
Les objets GMP (GNU Multiple Precision) supportent maintenant la surcharge des opérateurs et le transtypage en types scalaires.

Plus de détails sont disponibles dans la suite de cette dépêche.

Nouveautés

Les expressions de constantes scalaires

Il est maintenant possible de définir des constantes d'après le résultat d'opérations effectuées sur d'autres constantes. Il est également possible de les utiliser dans les déclarations de propriété et dans les arguments par défaut de fonctions.

Exemple tiré du site php.net :

const UN = 1;
const DEUX = UN * 2;

class C {
    const TROIS = DEUX + 1;
    const UN_SUR_TROIS = UN / self::TROIS;
    const RESULTAT = 'La valeur de TROIS est '.self::TROIS;

    public function f($a = UN + self::TROIS) {
        return $a;
    }
}

echo (new C)->f()."\n";
echo C::RESULTAT;

Résultat :

4
La valeur de TROIS est 3

Fonctions à nombre d'arguments variable

Les fonctions PHP peuvent accepter un nombre d'arguments variable, ceux-ci seront contenus dans un tableau défini grâce à l'opérateur …

Exemple :

function somme($arg1, $arg2 = null, ...$args){

    //$args est un array contenant les arguments restants
    //$count($args) représente le nombre d'arguments dans $args
    return $arg1+$arg2+array_sum($args);
}

somme(1);
somme(1,2);
somme(1,2,3,4);

A noter que l'on peut utiliser le typage explicite.

Dés-empaquetage des objets

L'opérateur ... peut aussi être utilisé lors de l'appel de fonction pour dés-empaqueter un tableau ou tout objet parcourable par foreach.

Exemple tiré du site php.net :

function add($a, $b, $c) {
    return $a + $b + $c;
}

$operators = [2, 3];
echo add(1, ...$operators);

L'opérateur `**` pour l'exponentiation

L'opérateur ** représente l'exponentiation, l'opérateur **= est utilisé pour l'assignation.

Exemple :

$a = 2**3**2; // $a = 512
$a **= 5; // $a = 35184372088832

Attention, cet opérateur est associatif à droite :
2 ** 3 ** 2 est équivalent à 2 ** (3 ** 2).

Extension du mot-clé use

Depuis PHP 5.3, il est possible d'importer des classes avec l'opérateur use.
Il est maintenant possible d'importer des fonctions ou des constantes.

Exemple tiré du site php.net :

namespace Name\Space {
    const FOO = 42;
    function f() { echo __FUNCTION__."\n"; }
}

namespace {
    use const Name\Space\FOO;
    use function Name\Space\f;

    echo FOO."\n";
    f();
}

phpdbg

Utilisable pour PHP >= 5.4 et inclus dans PHP 5.6, phpdbg est un débogueur complet utilisable sans impact sur les performances ni sur les fonctionnalités du code.

Son objectif est d'être léger, puissant et simple à utiliser.

Ré-utilisabilité de `php://input`

Les flux php:// sont des flux d'entrée/sortie fournis par PHP. Le flux php://input permet d'accéder en lecture seule aux données brutes depuis le corps de la requête.

Dans le cas de requêtes POST, il se substitue maintenant à la variable $HTTP_RAW_POST_DATA qui nécessitait l'activation de always_populate_raw_post_data boolean dans le php.ini pour inclure les type MIME reconnus.

Utilisation :

$postdata = file_get_contents("php://input");

Ce nouveau mécanisme a également permis de réduire significativement la quantité de mémoire requise lors des opérations POST.

Problèmes de compatibilité

Quelques incompatibilités sont à prévoir pour cette nouvelle version. Comme à l'accoutumée, il est conseillé de lire (en anglais) la page de migration de php5.5 vers php5.6.

Les principales incompatibilités se situent au niveau des changements OpenSSL :
Tous les flux clients chiffrés activent désormais par défaut la vérification par paire.

A noter également, la fonction json_decode sera légèrement plus stricte puisque les inputs true, false et null seront refusés s'ils ne sont pas entièrement en minuscule.

Le Futur

PHP7

PHP s'oriente vers la version 7. Après quelques débats, il a été choisi de sauter la version 6. En effet, ce projet échoué, devant notamment rendre PHP entièrement compatible avec Unicode, possédait trop de référence et de livres consacrés. Les principales nouveautés de PHP6 ont d'ailleurs déjà été incluses au fil de l'eau dans >= PHP5.3. PHP7 n'a définitivement pas les même objectifs.

PHPNG et compilation à la volée

Comme expliqué ici (en anglais), PHP7 repart sur les bases de PHPNG. Concrètement, il s'agit avant tout de se doter d'un nouveau moteur bien plus performant que le Zend Engine actuel.

Ce gain de performance pourra être accentué par le compilation à la volée (JIT : Just In Time) qui devrait être implémenté par Dmitry Stogov. Il annonce 10 à 20 pourcent de vitesse en plus sur des applications réelles : Wordpress 3.6 (+20%), Dupral 6.1 (+11.7%) …

Syntaxe d'arbre abstraite

Quelques changements de syntaxe et de fonctionnement du compilateur pourrait également être inclus dans la version 7 pour profiter de performances encore supérieures.

PHP vs HACK

Le langage HACK et sa machine virtuelle HHVM ont été dévoilés il y a quelques mois par Facebook. Une dépêche avait été publiée pour l'occasion. En grande partie compatible avec PHP, ce langage apporte notamment le typage statique, l'écriture de squelettes HTML protégés des failles XSS, la programmation asynchrone. HHVM, quant-à-elle, propose la compilation à la volée et peut faire tourner du PHP.

Il ne fait aucun doute que ce sera un concurrent très sérieux pour PHP et que cela incitera ses mainteneurs à le faire évoluer rapidement pour ne pas se laisser distancer.

Aller plus loin

# Spécifications

Posté par Laurent J (site web personnel, Mastodon) le 09 septembre 2014 à 10:45. Évalué à 10.

À noter qu'il n'y avait jusqu'à présent pas de spécification officielle du langage PHP, vu qu'il n'y avait qu'un moteur PHP. Mais depuis l'apparition de moteurs PHP alternatifs (comme HHVM), il devenait important qu'il y en ait une. C'est donc un travail en cours, et cela va permettre à une meilleure compatibilité entre tous ces moteurs.
# Objectifs ?

Posté par barmic le 09 septembre 2014 à 10:52. Évalué à 5.

PHP7 n'a définitivement pas les même objectifs [que PHP6].

Les quels sont-ils ? Uniquement de la perf (JIT&AST) ?

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: Objectifs ?
  
  Posté par pascalc le 09 septembre 2014 à 11:28. Évalué à 10.
  
  La perf semble être l'un des principaux objectifs, il y a aussi des nettoyages cassant légèrement la compatibilité ascendante qu'ils ne se permettaient pas sur 5.x, l'un des gros patchs qui a landé juste après la fusion de la branche PHPNG (réécriture du moteur dans un objectif de perfs) est l'amélioration et l'harmonisation du support 64 bits entre les plateformes (OS) supportés.
  
  La liste des choses déjà implémentées est là:
  https://wiki.php.net/rfc#php_70
  
  Je pense que la principale raison pour laquelle il y a un changement de version majeure est que de nombreuses améliorations voulues par les développeurs ne passeraient pas le vote pour 5.x car ils casseraient (un peu) la compatibilité ascendante. Le système de roadmap de PHP6 a été une catastrophe pour le projet puisque ne parvenant pas à maintenir la branche 5.x et à atteindre tous les objectifs de la 6 en même temps par manque de bras, la 6 n'est jamais sortie mais des fonctionnalités majeures pourtant prêtes sur la branche 6 ne sortaient pas non plus. L'abandon de la 6 a conduit à la 5.3 avec le gros des fonctionnalités backportées, puis en 2011 à un nouveau cycle de release annuel où ils livrent ce qui est prêt quand c'est prêt et tout changement passe par un système de RFC avec patch associé obligatoire plutôt que par une feuille de route yakafokon ;) (plus agile en fait, ils sont aussi passé sur github + travis). Donc pour savoir ce qu'il y aura dans la 7, il faut suivre les RFC (en gros il y a une nouvelle RFC par semaine) et leur implémentation.
# Noms de fonctions dans la bibliothèque standard

Posté par rewind (Mastodon) le 09 septembre 2014 à 11:31. Évalué à 5.

Est-ce qu'il est prévu dans PHP7 d'harmoniser les noms (et le comportement) des fonctions de la bibliothèque standard ?
- [^] # Re: Noms de fonctions dans la bibliothèque standard
  
  Posté par rewind (Mastodon) le 09 septembre 2014 à 11:40. Évalué à 5.
  
  Je me réponds à moi-même : ils y pensent (mais c'est encore à un stade très précoce apparemment)
  - [^] # Re: Noms de fonctions dans la bibliothèque standard
    
    Posté par pascalc le 09 septembre 2014 à 11:49. Évalué à 5.
    
    De ce que j'ai lu sur la liste php-internals, ils ne sont pas chauds du tout pour ajouter plus d'alias au langage et ils n'introduiront jamais non plus une cassure complète de la compatibilité ascendante qui reviendrait à tuer tout l'écosystème PHP, donc ça m'étonnerait que ça se fasse, en tout cas pas avec l'approche proposée par ce dev.
    - [^] # Re: Noms de fonctions dans la bibliothèque standard
      
      Posté par devnewton 🍺 (site web personnel) le 11 septembre 2014 à 10:28. Évalué à 4.
      
      Ils pourraient s'inspirer de Go: au lieu de maintenir la compatibilité en bloatant le langage, utiliser un programme de conversion des vieux codes sources.
      
      http://golang.org/cmd/fix/
      
      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
      - [^] # Re: Noms de fonctions dans la bibliothèque standard
        
        Posté par LupusMic (site web personnel, Mastodon) le 11 septembre 2014 à 12:42. Évalué à 2.
        
        Ce qui voudrait dire qu'il faut vérifier la version de PHP avant d'exécuter un script. Je rappelle que le succès de PHP est entre autres raisons du à sa totale absence de propreté.
        
        [^] # Re: Noms de fonctions dans la bibliothèque standard
        
        Posté par Antoine le 12 septembre 2014 à 00:51. Évalué à 2.
        
        Je rappelle que le succès de PHP est entre autres raisons du à sa totale absence de propreté.
        
        C'est gentil de rappeler, ce serait mieux d'étayer…
        
        [^] # Re: Noms de fonctions dans la bibliothèque standard
        
        Posté par barmic le 12 septembre 2014 à 10:58. Évalué à 2.
        
        Je ne suis pas un spécialiste du PHP mais le fait qu'il y ai des choses pas très propres n'est AMHA plus à démontrer ne serait-ce que l'absence de convention de nommage ou les méthodes qui renvoie une map à la fois indexé sur des string et sur des entiers pour pouvoir être utilisé des deux façon, n'est pas quelque chose qui fait rêver.
        
        Après AMHA il est surtout populaire grâce à son typage laxiste et son "optimisation" pour le web (le fait qu'il s'intègre bien avec du HTML (même si oui aujourd'hui on peu faire mieux comme opa ou hack)).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Noms de fonctions dans la bibliothèque standard
        
        Posté par Antoine le 12 septembre 2014 à 13:31. Évalué à 4.
        
        Après AMHA il est surtout populaire grâce à son typage laxiste et son "optimisation" pour le web
        
        Historiquement il y a des facteurs objectifs à la popularité de PHP :
        - très bonne intégration avec Apache (les solutions en Perl et Python n'arrivaient pas à la cheville de mod_php)
        - technique de déploiement ultra-simple et compréhensible par tous (un fichier .php == une page, au même niveau que les fichiers statiques, et sans besoin d'autre chose qu'un accès FTP)
        - conséquence des deux premiers, disponibilité très large chez les hébergeurs pas chers (et même gratuits), dans des configuration assez proches de l'un à l'autre (donc migrations et consolidation de l'expérience acquise assez faciles)
        - APIs d'interaction avec MySQL en standard
        
        Tout ça rendait le choix de PHP absolument évident pour écrire des applis Web au début des années 2000 (l'efflorescence des *Nuke, SPIP, Drupal…). L'inertie et la force de l'existant font le reste.
        
        [^] # Re: Noms de fonctions dans la bibliothèque standard
        
        Posté par LupusMic (site web personnel, Mastodon) le 12 septembre 2014 à 13:47. Évalué à 3.
        
        très bonne intégration avec Apache (les solutions en Perl et Python n'arrivaient pas à la cheville de mod_php)
        
        Très mauvaise intégration, entraînant des problèmes de sécurité divers. En fait, il faudrait parler d'intégration simple à déployer et maintenir. Mais ce modèle a posé de nombreux problèmes par le passé, ayant entraîné des horreurs (openbasedir et autres mécanismes de pseudo-sécurité).
        
        un fichier .php == une page
        
        Alors certes, cela simplifie la vie de celui qui veut créer un compteur et quelques gadget pour un site personnel. Malheureusement, cette conception entraîne /de facto/ la création d'une surface d'attaque inimaginable.
        
        conséquence des deux premiers, disponibilité très large chez les hébergeurs pas chers
        
        C'est là qu'on est d'accord. PHP est à la programmation Web ce que MacDo est à la restauration. Et j'en mange trop (des deux).
        
        APIs d'interaction avec MySQL en standard
        
        Encore une fois, c'est vrai que c'est très pratique et permet de garantir des comportements, mais malheureusement, c'est un mauvais design. Une bonne pratique en sécurité, c'est de tout désactiver pour activer ce dont on a besoin. Mettre à disposition une API pour la dizaine de BDD qu'on n'utilisera jamais n'est pas un bon modèle de sécurité. Mais encore une fois, c'est un compromis coût/qualité.
        
        [^] # Re: Noms de fonctions dans la bibliothèque standard
        
        Posté par Antoine le 12 septembre 2014 à 14:10. Évalué à 3.
        
        intégration simple à déployer et maintenir
        
        N'est-ce pas là le critère principal d'une bonne intégration ?
        
        Malheureusement, cette conception entraîne /de facto/ la création d'une surface d'attaque inimaginable.
        
        "Inimaginable" ? C'est donc qu'elle n'est même pas réelle ? :-)
        
        C'est là qu'on est d'accord. PHP est à la programmation Web ce que MacDo est à la restauration.
        
        En 2000, tu avais le choix entre "MacDo" d'une part, quelques restaurants médiocres et totalement inabordables d'autre part. Le choix MacDo était donc le choix rationnel, loin d'une quelconque appétance pour la "saleté" qui reste totalement fantasmée.
        
        (je précise que c'est l'appétance qui est fantasmée, pas la saleté, pour prévenir un contresens de plus…)
        
        [^] # Re: Noms de fonctions dans la bibliothèque standard
        
        Posté par barmic le 12 septembre 2014 à 14:43. Évalué à 2.
        
        N'est-ce pas là le critère principal d'une bonne intégration ?
        
        Non, ça dépend des besoins, ça peut être la performance ou la sécurité par exemple.
        
        "Inimaginable" ? C'est donc qu'elle n'est même pas réelle ? :-)
        
        Non, les limites de stockage des systèmes de fichiers 128bits sont inimaginables mais existent bel et bien. Il y a pleins de quantité qui étaient inimaginables et sont devenu conventionnel aujourd'hui.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Noms de fonctions dans la bibliothèque standard
        
        Posté par LupusMic (site web personnel, Mastodon) le 12 septembre 2014 à 17:51. Évalué à 1.
        
        N'est-ce pas là le critère principal d'une bonne intégration ?
        
        Nope. En fait, les module de ce type sont des exemples de ce qu'il ne faut pas faire : introduire du code dans le serveur, alors qu'il peut, et devrait, être exécuté en dehors. Ici le problème est que PHP n'est pas intégré à Apache, mais y est greffé.
        
        "Inimaginable" ? C'est donc qu'elle n'est même pas réelle ? :-)
        
        Ah ben on va faire de la sémantique : inimaginable qualifie quelque chose, un concept, un phénomène, qui dépasse notre entendement. Ce qui n'est pas réel peut être imaginable, bien qu'inconcevable.
        
        En 2000, tu avais le choix entre "MacDo" d'une part, quelques restaurants médiocres et totalement inabordables d'autre part. Le choix MacDo était donc le choix rationnel, loin d'une quelconque appétance pour la "saleté" qui reste totalement fantasmée.
        
        Je suis tout à fait d'accord. Les problèmes qu'avaient entraîné les scripts CGI ont fait le lit d'outils comme PHP. PHP avait la qualité de ne pas être trop compliqué et de limiter ce que peut faire le propriétaire des pages en contournant le tabou des scripts CGI. Quand on a que des tomates pourries à manger, ben on les mange pour ne pas crever de faim.
        
        [^] # Re: Noms de fonctions dans la bibliothèque standard
        
        Posté par LupusMic (site web personnel, Mastodon) le 12 septembre 2014 à 12:34. Évalué à 1.
        
        Quiconque est expert en PHP connait http://phpsadness.com/
        
        [^] # Re: Noms de fonctions dans la bibliothèque standard
        
        Posté par Antoine le 12 septembre 2014 à 13:23. Évalué à 3.
        
        Expert dans l'art de répondre à côté ?
        
        Je reprends ta phrase : """le succès de PHP est entre autres raisons du à sa totale absence de propreté."""
        
        Ce qui n'est pas étayé, ce n'est pas que PHP soit sale (on est au courant), c'est que sa saleté soit précisément source de popularité.
        
        [^] # Re: Noms de fonctions dans la bibliothèque standard
        
        Posté par LupusMic (site web personnel, Mastodon) le 12 septembre 2014 à 13:37. Évalué à 2.
        
        MS DOS
        Basic
        MS Windows
        Spreadsheets
        etc
        
        En fait, l'excellence technique est souvent la garantie de l'échec. Je pense que c'est dû à un problème de viabilité économique. La propreté et l'excellence demandent plus de temps (et donc d'argent) à concevoir et à assimiler. Du coup, ce sont des solution qui sont entre la civilisation et la barbarie qui réussissent, avec une nette tendance à pencher vers la barbarie.
        
        Un autre facteur important à prendre en compte est aussi l'aspect décomplexant d'une solution bancale. Un débutant sera mins gêner pour écrire du code dégueulasse dans un environnement dégueulasse, qui permet le code dégueulasse créé d'être cependant fonctionnel. C'est comme un sol : sur un sol propre, on a pas envie de marcher parce qu'on ne veut pas saloper (et entre maman gueuler qu'elle vient juste de nettoyer et qu'elle a pas envie de passer la serpillière toutes les 5 minutes !).
        
        [^] # Re: Noms de fonctions dans la bibliothèque standard
        
        Posté par Antoine le 12 septembre 2014 à 13:52. Évalué à 2.
        
        Tout ça se résume à des "je pense que" et à des pétitions de principe. Le seul élément tangible, c'est le "worse is better" mis en avant par Richard Gabriel : http://en.wikipedia.org/wiki/Worse_is_better . Mais cela n'implique pas une mauvaise conception, simplement des compromis entre la simplicité et la perfection formelle.
        
        Or il y a des critères objectifs au succès de PHP, voir plus haut. Il n'y a pas de raison de penser que la "saleté" fasse partie de ces critères, et l'idée que les gens n'aiment pas "marcher sur des sols propres" est ridicule (crois-tu que les gens préfèrent entrer dans un magasin propre ou un magasin sale ? le fait que la plupart des magasins essaient de rester propres répond à la question…).
# json_decode()

Posté par WhiteCat le 09 septembre 2014 à 13:56. Évalué à 3.

A noter également, la fonction json_decode sera légèrement plus stricte puisque les inputs true, false et null seront refusés s'ils ne sont pas entièrement en minuscule.

À noter que cette correction de bug (qui engendre un "problème" de compatibilité possible en cas de mise à jour) est déjà incluse dans les versions antérieures de PHP, notamment la 5.4.23 et la 5.3.3 (qui est celle de RHEL 6). Par contre pour la branche 5.5 je ne sais pas.

En somme, si vous traitez du JSON en PHP, je vous conseille de vérifier ce cas de figure.
# Coquille

Posté par eltoniodelavega le 10 septembre 2014 à 20:14. Évalué à 1.

§ exponentiation:
s/utlisé/utilisé/
- [^] # Re: Coquille
  
  Posté par Benoît Sibaud (site web personnel) le 10 septembre 2014 à 20:59. Évalué à 3.
  
  Corrigé, merci.
# Avec un jour d'avance...

Posté par FantastIX le 11 septembre 2014 à 11:12. Évalué à -2.

C'est moi ou bien PHP commence à ressembler de plus en plus à Python?

-->[]
# On aura toujours le droit à nos segfault préférées !?

Posté par DrGkill le 19 septembre 2014 à 15:18. Évalué à 0.

Aura t-on toujours droit à nos segfault préférées que l'on rencontre régulièrement depuis quelques années ?
[5054807.449481] php5-fpm[27874]: segfault at 1000721 ip 00000000006ac537 sp 00007fff3f39ccd0 error 4 in php5-fpm[400000+6ff000]
Sinon elles vont me manquer …