La version 7.0 de PHP a été annoncée ce jeudi 3 décembre 2015. Elle améliore très significativement les performances, ajoute de nouvelles fonctionnalités et fait un ménage conséquent. Le pari d'une modernisation complète de ce langage phare du développement web est-il réussi après deux années complètes de développement ? Début de réponse dans cette dépêche.
Sommaire
- Résumé des plus gros changements
-
Dans le détail
- Amélioration des performances
- Amélioration de la structure du compilateur
- Exceptions (hiérarchie et ajouts)
- Générateur de nombres aléatoires sécurisé
- Nettoyage SAPI et extensions
- Déclarations de type dans les fonctions : retours et scalaires
- Classes anonymes
- Expectations, assertions à coût nul
- Nouvel opérateur null coalescing : ??
- Nouvel opérateur de comparaison : <=>
- Incompatibilités
It is not just a next major PHP version being released today. The release being introduced is an outcome of the almost two years development journey. It is a very special accomplishment of the core team. And, it is a result of incredible efforts of many active community members. Indeed, it is not just a final release being brought out today, it is the rise of a new PHP generation with an enormous potential.
Ce n'est pas seulement une nouvelle version majeure de PHP qui sort aujourd'hui. C'est l'aboutissement de pratiquement deux ans de développement. Une performance remarquable de la « core team ». Et, c'est le résultat d'efforts incroyables de la part de nombreux membres actifs de la communauté. En effet, ce n'est pas simplement une version finale qui sort aujourd'hui, c'est la naissance d'une nouvelle génération de PHP avec un potentiel énorme.
C'est par ces mots que l'équipe de développement de PHP a annoncé la dernière version de leur langage. Et ce n'est pas rien, on se souviendra que les tentatives de développement de PHP 6 avaient échoué en 2010 poussant l'équipe à fusionner une partie des nouveautés à PHP 5.4 en abandonnant temporairement le travail sur Unicode.
Résumé des plus gros changements
PHP 7.0 entre en scène avec un nouveau moteur Zend Engine et des nouvelles fonctionnalités telles que :
- Prise en charge cohérente du 64 bits ;
- Amélioration de la hiérarchie des exceptions ;
- De nombreuses erreurs fatales converties en exceptions ;
- Un générateur de nombres aléatoires sécurisé ;
- Suppression des interfaces SAPI et des extensions obsolètes ou non-maintenues ;
- Typage des déclarations de fonction : retours et scalaires ;
- Classes anonymes ;
- Assertions à coût nul ;
- Un nouvel opérateur null coalescing :
??: - Un nouvel opérateur de comparaison :
<=>.
Comme promis, ce nouveau Zend Engine est beaucoup plus performant. On parle d'une réduction par quatre du nombre d'instructions CPU pour exécuter une requête WordPress (comparé à PHP 5.6 ; voir source). Et Zend annonce également de meilleures performances que HHVM 3.7. De plus, il aurait réduit significativement l'utilisation de la mémoire.
Dans le détail
Amélioration des performances
Avant toute explication, il est nécessaire de parler de HHVM. Cette machine virtuelle pour PHP et HACK ont été développés par Facebook. HHVM a apporté un gain substantiel de performance. Pour ne pas se laisser distancer, l'entreprise Zend lance en janvier 2014 un projet interne pour optimiser les structures de données de PHP, sous la direction de Dimitri Stogov. Les premiers résultats sont prometteurs, et en mars une RFC baptisée PHPNG propose de refonder le cœur de PHP. C'est sur ces bases que PHP 7 a été construit ; l'équipe en montre donc fièrement les nouvelles performances.
Zend a publié une longue infographie d'un banc d'essai comparant le nombre de requêtes par secondes pouvant être effectuées sur différents CMS : Drupal, WordPress, Magento, Laravel, Zend Framework, Sugar CRM. De manière générale on remarquera que PHP 7 sert en moyenne 1,8 fois plus de requêtes que PHP 5.6 et légèrement plus que HHVM 3.7. On prendra ces chiffres avec des pincettes du fait de leur description imprécise et de leur origine (Zend), l'entreprise ayant intérêt à présenter PHP sous le meilleur jour possible. On notera aussi que HHVM s'en sortirait mieux pour le calcul lourd (ce qui n'est pas nécessairement la cible de base du développement de sites web).
On peut aussi mesurer l'évolution des performances dans ce graphique retraçant le nombre d'instructions du processeur pour une même page WordPress tout au long du développement de PHP 7 en 2014.
PHP 7 devait aussi apporter une compilation à la volée, nous en parlions en ces termes dans la dépêche annonçant la sortie de PHP 5.6 :
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 %) et Drupal 6.1 (+ 11,7 %)…
Malheureusement, cette nouvelle évolution se fait attendre. HHVM étant parti pour lancer une nouvelle offensive sur le sujet, PHP fera tout pour rester dans la course.
Amélioration de la structure du compilateur
Auparavant, l'analyse syntaxique d'un code source PHP était imbriquée dans le compilateur PHP. Cette nouvelle version utilise en amont de la compilation un arbre syntaxique abstrait, ou AST pour Abstract Syntax Tree. Ce découplage, avec désormais une phase d'analyse syntaxique avant la production des opcodes, a permis de retirer du compilateur quelques subterfuges peu présentables pour obtenir un code de maintenance plus facile.
Si l'impact sur les performances est négligeable, cette amélioration ouvre des perspectives sur la syntaxe du langage. Une application pratique immédiate est que yield peut maintenant s'utiliser sans parenthèses.
L'AST est une structure intermédiaire utilisée durant le processus de compilation. Elle remplace l'utilisation d'opcodes (liste d'opérations à effectuer par la suite).
Désolidariser l'analyseur syntaxique du compilateur permet de supprimer un grand nombre de bricolages et rend le code plus facilement maintenable et compréhensible en général. De plus, cela permet de mettre en oeuvre des syntaxes qui ne sont pas interprétables avec une seule passe d'analyse.
L'implémentation de l'AST est 10 à 15 % plus rapide que la compilation standard. En revanche, elle est plus consommatrice en mémoire en fonction de la taille des fichiers.
Quelques changements de syntaxe et de fonctionnement ont été nécessaires pour permettre l'implémentation de l'AST.
Un autre changement structurel apporte plus de cohérence dans le support du 64 bits. Avant PHP 7, il n'y avait pas de type entier 64 bits. La taille dépendait du système d'exploitation, avec notamment PHP/Windows qui restait en 32 bits et émulait les entiers longs. La proposition d'uniformiser ce comportement a été acceptée de justesse et implémentée en PHP 7, après correction des extensions comme PDO qui avaient des préjugés sur les tailles des entiers.
Changement dans l'affectation des listes
Les listes sont maintenant affectées de gauche à droite.
list($array[], $array[], $array[]) = [1, 2, 3];
var_dump($array);
// AVANT: $array = [3, 2, 1]
// MAINTENANT: $array = [1, 2, 3]D'autres exemples d'affectation :
$a = [1, 2];
list($a, $b) = $a;
// AVANT: $a = 1, $b = 2
// MAINTENANT: $a = 1, $b = null + "Undefined index 1"
$b = [1, 2];
list($a, $b) = $b;
// AVANT: $a = null + "Undefined index 0", $b = 2
// MAINTENANT: $a = 1, $b = 2Les listes vides sont toujours interdites :
list() = $a; // INVALID
list($b, list()) = $a; // INVALID
foreach ($a as list()) // INVALID (c'était déjà le cas avant)Influence des parenthèses
Une conséquence de l'Uniform Variable Syntax RFC était que ($foo)['bar'] = 'baz' et $foo['bar'] = 'baz' n'avaient pas le même comportement car ils étaient compilés avec des méthodes de recherche différentes. Ce problème est maintenant résolu, les comportements que l'on peut attendre seront ceux observés.
Yield est maintenant associatif à droite
Le constructeur yield n'a plus besoin de parenthèse et est associatif à droite.
echo yield -1;
// Etait interprété comme
echo (yield) - 1;
// Est maintenant interprété comme
echo yield (-1);
yield $foo or die;
// Etait interprété comme
yield ($foo or die);
// Est maintenant interprété comme
(yield $foo) or die;D'autres conséquences et informations peuvent être trouvées sur la page de la RFC.
Exceptions (hiérarchie et ajouts)
Depuis PHP 7, le moteur peut envoyer des exceptions au lieu de lancer des erreurs fatales. En effet, jusqu'à présent, la moindre erreur fatale faisait arrêter le processus immédiatement ce qui peut être génant dans le cas d'un serveur ou d'un démon écrit en PHP. Grâce aux exceptions, il sera par exemple possible d'attraper une exception, fermer proprement les entrées/sorties nécessaires et continuer de servir les autres requêtes.
La RFC décrit aussi l'exemple d'une batterie de tests en PHPUnit qui peut continuer à s'exécuter même si un des tests renvoie une erreur fatale.
La RFC introduit donc deux nouveaux types d'exception :
- EngineException : exception envoyée par défaut à l'exécution ;
- ParseException : pour les exceptions liées au parsing.
Elle change les règles suivantes :
- Il est maintenant possible d'utiliser des exceptions dans le moteur PHP ;
- Les erreurs précédemments utilisées :
E_ERROR,E_RECOVERABLE_ERROR,E_PARSEOUE_COMPILE_ERRORsont converties en exceptions ; - Il est maintenant découragé d'introduire de nouvelles erreurs de type
E_ERRORouE_RECOVERABLE_ERROR. Dans les limites de la faisabilité, il faut préférer les exceptions.
Pour conserver une certaine compatibilité, les erreurs classiques avec leurs messages seront conservées si les exceptions de moteur ou de l'analyseur ne sont pas attrapées. Cela pourrait être changé à l'avenir. Il existe donc quelques incompatibilités mais la plupart des anciens codes devrait continuer à fonctionner.
Générateur de nombres aléatoires sécurisé
Un générateur de nombre pseudo-aléatoire cryptographiquement sécurisé a été ajouté. Il apporte (RFC) deux nouvelles fonctions : random_bytes() et random_int().
$randomStr = random_bytes($length = 16);
$randomInt = random_int($min = 0, $max = 127);Pour générer ces nombres, le moteur utilisera :
- Sur Windows : exclusivement CryptGenRandom ;
- arc4random_buf() s'il est disponible (souvent spécifique à BSD) ;
- /dev/arandom s'il est disponible ;
- /dev/urandom si aucun des précédents n'est disponible ;
- Une exception sera envoyée si la source d'aléatoire n'est pas suffisante. (RFC).
Ces ajouts permettent de ne plus avoir à utiliser mcrypt_create_iv() qui demandait d'installer l'extension MCrypt ni openssl_random_pseudo_bytes apportée par OpenSSL lib.
Nettoyage SAPI et extensions
Une modification de taille, annoncée depuis des années, est la suppression de « ext/mysql », l'API historique de MySQL dans PHP. La fameuse mysql_real_escape_string() (qui est real par opposition à mysql_escape_string() qui n'est pas sûre), cette fonction omni-présente au temps de PHP 4 a vécu. L'extension MySQL est avantageusement remplacée par les API (fonctionnelles ou orientées-objets, au choix) de Mysqli ou PDO.
Les extensions ereg (expressions rationnelles pre-preg), mssql (PDO s'y substitue) et sybase_ct ont aussi été supprimées.
Quinze SAPI ont été retirées du code. Par exemple, la SAPI « apache » était une ancienne méthode d'intégration de PHP à Apache, alors qu'aujourd'hui « fpm » est recommandée, ou à défaut en module avec mod_php qui correspond généralement à la SAPI « apache2handler ».
Côté SAPI, noter que quand PHP-FPM écoute sur un port donné, il le fait en IPv4, et désormais aussi en IPv6, par défaut.
Déclarations de type dans les fonctions : retours et scalaires
Déclaration de type scalaire
Les déclarations de type existent depuis PHP 5 et permettent de demander un certain type à l'appel d'une fonction. Par contre seuls les classes, interfaces, tableaux et le type callable étaient disponibles. PHP 7 ajoute donc le typage des scalaires (string, int, float et bool) avec deux modes : coercitif (par défaut) et strict (voir ci-dessous).
À l'exécution, si l'argument donné est de mauvais type, PHP 7 lancera une exception TypeError. PHP 5 provoquait une erreur fatale.
function foo(int $foo, int $bar)
{
echo $foo + $bar;
}
foo(1, 1); // affiche 2
foo(1, '1'); // affiche 2 (conversion car mode coercitif)
foo('a', 1); // Uncaught TypeErrorToute la documentation concernant la déclaration de type peut être trouvée ici.
Déclaration du type renvoyé
PHP 7 permet la déclaration du type de la valeur retournée par une fonction.
function countNonBlank(array $lines) : int
{
return count(array_filter(array_map('trim', $lines)));
}Typage strict
Par défaut, PHP va convertir les mauvais types vers le type scalaire attendu tant que possible. Par exemple, une fonction, qui attend comme paramètre un integer (entier), et à laquelle est passée une string (chaîne de caractères) recevra une variable de type string.
Il est possible d'activer un typage strict fichier par fichier. Dans ce mode, seule une variable exactement du type attendu dans la déclaration sera acceptée, sinon une exception du type TypeError sera levée. La seule exception à cette règle est qu'un entier (integer) peut être passé à une fonction attendant un nombre flottant (float).
Le typage strict affecte aussi les déclarations de type retourné. Alors qu'en typage faible, le valeur de retour est convertie vers le type déclaré, en typage strict une exception sera levée.
Ce mode est activé fichier par fichier grâce à l'expression declare.
declare(strict_types=1);
function sum(int $a, int $b) {
return $a + $b;
}
var_dump(sum(1, 2)); // retourne int(3)
var_dump(sum(1.5, 2.5)); // Uncaught TypeExceptionLe mode strict est à surveiller de près car il ne s'applique qu'aux appels de fonctions effectués depuis l'intérieur d'un fichier dont le typage strict est actif. Autrement dit, si un fichier dont le typage strict n'est pas activé effectue un appel à une fonction qui a été définie dans un fichier dont le type strict est actif, la préférence de l'appelant sera respectée, le typage ne sera donc pas strict.
Classes anonymes
L'opérateur new peut désormais être suivi de la déclaration d'une classe anonyme, au lieu du nom d'une classe existante. L'exemple suivant illustre ce principe.
function createLogger() {
return new class implements \IteratorAggregate {
private $content = [];
public function add(string $item) {
$this->content[] = $item;
return $this;
}
public function getIterator() {
return new \ArrayIterator($this->content);
}
};
}
$logger = createLogger();
$logger->add("jusqu'ici tout va bien")->add("ça baigne");
foreach ($logger as $log) {
echo $log . "\n";
}Expectations, assertions à coût nul
La fonction assert() devient une composante du langage PHP 7, ce qui lui permet d'être plus souple et plus performante.
Avant PHP 7, le premier paramètre de assert() était évalué, même quand les assertions étaient désactivées, avec le risque de ralentir ou perturber l'exécution en production. Une astuce douteuse était de placer le code PHP dans une chaîne de caractère, laquelle n'était évaluée que lorsqu'on avait activé les assertions.
// Avant PHP 7
// Activer les assertions
assert_options(ASSERT_ACTIVE);
// La fonction sera appelée, même sans ASSERT_ACTIVE
expect(slowButTrue(), "Problème avec slowButTrue()");
// Le texte sera évalué seulement avec ASSERT_ACTIVE
expect("slowButTrue()", "Problème avec slowButTrue()");En PHP 7, l'ancienne syntaxe reste valable, mais passer le réglage zend.assertions à 0 (contre 1 par défaut) permet de désactiver l'évaluation des assertions. On peut aussi déclencher des exceptions, dérivées de la nouvelle classe réservée AssertionError.
// PHP 7
// Activer les assertions (ou mieux, dans php.ini)
ini_set('zend.assertions', 1);
// Si les assertions sont désactivées, pas d'évaluation
expect(slowButTrue(), "Problème avec slowButTrue()");
// Remplacer les messages d'erreurs par des exceptions
ini_set('assert.exception', 1);
assert(false, new AssertionError('Ça va mal'));Nouvel opérateur null coalescing : ??
Cet opérateur ajoute du sucre syntaxique pour les cas courants d'utilisation d'un opérateur ternaire couplé à la fonction isset() qui permet de savoir si une valeur existe.
?? retourne le premier opérande s'il existe et s'il n'est pas NULL, sinon il retourne le deuxième.
// code d'avant PHP 7
return isset($a) ? $a : 0;
// code en PHP 7
return $a ?? 0;
// combinaison ?? en PHP 7
return $_GET["user"] ?? $_POST["user"] ?? "anonyme";Comme illustré ci-dessus, l'opérateur peut être chainé, et retournera alors la première valeur définie parmi plusieurs opérandes consécutifs.
Nouvel opérateur de comparaison : <=>
Dérivé de Perl et consorts à travers la RFC « Combined Comparison (Spaceship) Operator », cet opérateur fonctionne comme les fonctions tri-valuées strcmp() ou version_compare() mais il a l'avantage de pouvoir être utilisé quelles que soient les valeurs, avec la même sémantique que <, <=, ==, >=, >. De nombreux exemples sont trouvables sur la page de la RFC.
Il donne les résultats suivant :
-
0si les deux opérandes sont égaux ; -
1si l’opérande de gauche est plus grand que celui de droite ; -
-1si l’opérande de gauche est plus petit que celui de droite.
Incompatibilités
Comme toujours, la liste des incompatibilités et le guide des migrations est disponible.
Aller plus loin
- Annonce de sortie de PHP 7.0 (462 clics)
- Article Wikipédia de PHP (257 clics)
- Dépêche LinuxFr.org : sortie de PHP 5.6 (148 clics)
- Aide de migration à PHP 7 (incompatibilités, nouvelles features, ...) (376 clics)
# Quelques précisions sur les perfs
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 10.
Pas besoin de pincettes. Les améliorations ont été largement confirmées par d'autres sociétés sur des vrais infrastructures. J'ai eu des retours sur des boites qui ont fait des tests et qui vont diminuer de manière significative le nombre de leur serveurs PHP grâce à PHP7.
Dans l'une des conférences au Forum PHP de cette année, celle de Zeev Suraski si je ne me trompe pas (l'un des créateurs du zend engine), il expliquait qu'ils s'étaient lancés dans le JIT. Mais les benchs avaient montrés que les améliorations sur les perfs n'étaient pas au rendez-vous, en tout cas, pas dans des cas normaux, c'est à dire sur des vrais sites web. Donc ils ont abandonnés l'idée. Donc à mon avis, on va longtemps attendre cette évolution qui n'apporte à priori peu d'avantage avec l'architecture actuelle du zend engine.
Ils ont par contre découvert qu'ils pouvaient faire beaucoup d'amélioration coté occupation mémoire, avec des bénéfices coté perf (moins de mémoire occupée, ça fait moins de travail pour la gestion de la mémoire entre autre). Et les résultats sont là.
[^] # Re: Quelques précisions sur les perfs
Posté par kursus_hc . Évalué à 5.
Une bonne nouvelle indirecte est que les hébergeurs (de mutualisés notamment) doivent tous être sur le qui-vive pour proposer cette version le plus rapidement possible.
[^] # Re: Quelques précisions sur les perfs
Posté par ʭ ☯ . Évalué à 6.
Pas sûr : il y a incompatibilité, il faut donc migrer manuellement, donc les perfs compteront peu par rapport à coût de la main d'oeuvre.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Quelques précisions sur les perfs
Posté par kursus_hc . Évalué à 4.
Peu importe, les hébergeurs ont toujours intérêt à le proposer (pas l'imposer) au plus vite.
[^] # Re: Quelques précisions sur les perfs
Posté par zurvan . Évalué à 2.
oui, j'imagine que pour les pages perso de free, ça va arriver d'ici 15 ou 20 ans…
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Quelques précisions sur les perfs
Posté par Jean-Max Reymond (site web personnel) . Évalué à 4.
tu peux déjà tourner en php 5.6 sur les serveurs de Free: http://les.pages.perso.chez.free.fr/migrations/php5v6.io
Pour ma part, je suis en 5.6 depuis quelques mois
[^] # Re: Quelques précisions sur les perfs
Posté par zurvan . Évalué à 4.
oui, c'est tout nouveau (et tout castré, pas de sqlite3, bien bidouillé aussi, je n'ai pas réussi à faire tourner la dernière version de phpBB3 dessus). Mais avant, jusqu'en août / sept 2015, on n'avait que php 5.1 qui date de… 2005 !
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Quelques précisions sur les perfs
Posté par ʭ ☯ . Évalué à 2.
Tu râles bien sur un service gratuit, puisqu'il n'exige même pas de s'abonner en payant auprès du FAI?
Pour ma part, être obligé d'utiliser MySQL ou postgreSQL plutôt que SQLite n'est pas vraiment pénalisant. Mais je suppose que tu as lancé un meilleur hébergements gratuits? Mon expérience ailleurs a été des comptes
ferméssupprimés alors qu'il ne contrevenaient pas aux CG. Chez Free, jamais de compte fermé, je le recommande à toutes les petites assos qui n'ont pas les moyens de s'héberger…⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Quelques précisions sur les perfs
Posté par zurvan . Évalué à 3.
bonjour,
oui, je râle bien sur un service "gratuit", que j'utilise suite à mon abonnement chez Free depuis plus de 15 ans. Qu'ils permettent à tout le monde d'en profiter même sans être client chez eux, c'est leur droit (l'intérêt c'est que ça leur permet de gonfler le trafic vers leurs serveurs et d'améliorer leurs négociation pour le peering http://www.nouveauinfo.com/2013/10/le-peering-petite-cuisine-entre-geants.html ), mais ils pourraient au moins proposer à leurs abonnés un hébergement de compte perso avec un peu plus de moyens qu'un seul admin pour gérer tout ça… (de plus ils ferment quand même les sites qui se sont fait hackés, ce qui n'est pas forcément un mal en soi mais après il faut aller pleurer sur la mailing list).
Et non, je n'ai pas lancé un meilleur hébergement gratuit, je n'ai pas les mêmes moyens financiers que free.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Quelques précisions sur les perfs
Posté par barmic . Évalué à 2.
Le fait qu'il soit gratuit le rend-t'il dénué de défaut ?
Sans en lancer un à soit, la comparaison avec les versions gratuites d'heroku par exemple, peuvent être intéressant, non ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Quelques précisions sur les perfs
Posté par pascalc . Évalué à 7.
La plupart des frameworks et CMS actuels sont déjà compatibles PHP 7, évidemment dans leurs versions récentes. De ce que j'ai testé, même des applis qui n'ont pas été testées sous PHP 7 comme Dotclear mais qui ont toujours fait attention à ne pas utiliser de fonctionnalités marquées comme E_DEPRECATED tournent sans aucun changement.
Si je regarde mon propre code, tout ce que j'ai écrit depuis 2011 (quand j'ai commencé à m'intéresser à faire du code plus pérenne, à ne jamais avoir la moindre notice ou warning dans mes logs, à suivre les recommandations PSR…) tourne sans aucun ajustement sous PHP 7. Ce que j'ai écrit avant était plus du PHP 4 que 5 en fait et je ne sais pas s'il tourne avec PHP 7, probablement pas, mais la compatibilité ascendante avec tout ce qui est sorti depuis 5 ans est très bonne en tous cas. Après, c'est à chacun de voir s'il veut passer du temps à migrer du vieux code d'il y a 10 ou 20 ans à PHP 7, mais pour du code en production maintenu correctement et si on ne parle pas de centaines de milliers de lignes de code, ça ne devrait pas être un boulot énorme.
[^] # Re: Quelques précisions sur les perfs
Posté par Nicolas (site web personnel) . Évalué à 5.
Mais si Dotclear est testé avec PHP 7 depuis les premières beta.
[^] # Re: Quelques précisions sur les perfs
Posté par pascalc . Évalué à 3.
C'est pas ce que m'a dit le lead dev (Frank Paul) qui était tout surpris et heureux de savoir que ça tournait avec PHP 7 (manque de communication entre les devs Dotclear ? ;) )
https://twitter.com/franckpaul/status/665543117148397568
[^] # Re: Quelques précisions sur les perfs
Posté par pascalc . Évalué à 8.
Sur OVH, il est déjà possible de passer son mutu en PHP 7:
https://forum.ovh.com/showthread.php/106907-Testez-PHP7-en-avant-premi%C3%A8re
[^] # Re: Quelques précisions sur les perfs
Posté par _jordan_ . Évalué à 4.
Je pensais surtout à la comparaison avec HHVM. Comme les deux se talonnent, il n'est pas impossible que les chiffres choisis dans l'infographie soient ceux donnant le meilleur jour de PHP 7.
[^] # Re: Quelques précisions sur les perfs
Posté par David Carlier . Évalué à 2.
Justement, quelqu'un sait-il s'il est maintenant encore intéressant d'utiliser HHVM ?
Juste par curiosité, étant qu'HHVM ne tourne bien qu'apparemment sous Linux and OSX et on tourne exclusivement sous BSD …
[^] # Re: Quelques précisions sur les perfs
Posté par pascalc . Évalué à 10. Dernière modification le 10 décembre 2015 à 11:50.
La différence de perf HHVM/PHP 7 est pas énorme maintenant et j'ai l'impression que HHVM tire surtout son épingle du jeu sur des grosses infras (wikipedia, facebook…) ce qui est normal vu qu'il a été créé pour répondre aux problématiques de Facebook, le plus gros site web au monde (1 milliard d'uttilisateurs connectés en permanence). Par contre HHVM est compatible PHP mais pas entièrement, il y a tout de même de la réécriture de code à mettre en place pour tirer partie de HHVM alors que PHP 7 est largement une solution "drop-in" si on a du code relativement PHP récent.
De mon point de vue donc, PHP 7 est une solution de migration beaucoup plus simple et efficace, par contre si on a du vieux code PHP (genre pre-5.3), à mon avis il y a un gros boulot de nettoyage pour que ça marche dans PHP 7 ou dans HHVM, dans ce cas, vu qu'il faut réécrire plein de trucs, ça peut être intéressant de passer à Hack/HHVM plutôt que migrer à PHP 7.
Après, il est évident que tant php 7 que HHVM sont sur un chemin de convergence, il y a dans PHP 7 des nouveautés prises directement d'HHVM et Facebook participe à l'écosystème PHP, par exemple ils ont fourni la première spec officielle PHP qui a été adoptée par php.net et qui est maintenue conjointement par les deux équipes et pour chaque RFC de PHP 7, les devs HHVM donnent leur feedback et ont aussi un droit de vote.
Personnellement, je pense qu'HHVM a sa place dans l'écosystème PHP, ils ont la possibilité d'avancer plus vite que php.net étant donné leurs ressources humaines et des contraintes plus faibles (pas de consensus communautaire nécessaire par exemple) par contre l'équipe de PHP fait de mon point de vue des choix plus pérenne en regardant ce qui marche dans HHVM (et d'autres langages) et en implémentant que ce qui a un impact réel tout en maintenant une compatibilité ascendante maximale avec les dizaines de milliers de libs php existantes, ce qui n'est pas forcément un objectif d'HHVM qui peut donc implémenter et expérimenter des fonctionnalités plus rapidement mais pas forcément plus proprement. Si on lit la liste php-internals, on voit que même des devs facebook disent que la syntaxe de la feature X était pas forcément un bon choix et que si PHP.net implémente la feature plus proprement, ils feront évoluer HHVM et Hack pour se rapprocer de l'implém officielle.
Pour moi la grande qualité d'HHVM c'est d'avoir rebooté la communauté PHP sur les questions de performances, la compétition est une bonne chose et la collaboration aussi, sur ce coup, l'investissement de Facebook, Intel et Microsoft en plus de Zend et des centaines de contributeurs bénévole a vraiment fait évoluer le langage mais aussi l'écosystème PHP dans le bon sens.
# Gains de perf réels et impressionnant sur mon appli
Posté par pascalc . Évalué à 10.
Étant donné que PHP 7 est sorti, il était facile de vérifier par soi-même que effectivement les gains de perf et dé mémoire sont là et pas qu'un peu. Sur une vue spécifique je sais peu optimisées et peu performante sur une de mes applis voici les résultats:
PHP 5.6
Memory peak: 34340864 (32.75MB)
Elapsed time (s): 1.0683
PHP7
Memory peak: 8912896 (8.5MB)
Elapsed time (s): 0.402
Je n'ai pas changé une seule ligne de code de mon appli qui fonctionne parfaitement en PHP 7, apparemment je tombe pile poil dans du code qui a été particulièrement optimisé en PHP 7 (c'est une API externe JSON traitant des arrays de dizaines de milliers d'items à base de regex + un peu de calculs mathématiques), donc dans mon cas, les gains sont encore plus importants que ceux mis en avant par Zend, presque un facteur 3 pour le temps de calcul de la requête, conso mémoire divisée par 4.
Sur la plupart des autres vues plus simples de l'appli, je vois au moins 50% de perfs en plus, tant côté temps de génération que mémoire. Je pourrais probablement mettre la même appli sur un petit VPS pas cher au lieu d'un dédié péchu comme actuellement et ne perdre aucune performance (et inversement, en passant à PHP 7 sur le matos actuel je pourrais servir beaucoup plus de requêtes simultanées, mais j'ai pas encore à gérer le problème de se faire slashdotter ;) ).
[^] # Re: Gains de perf réels et impressionnant sur mon appli
Posté par zurvan . Évalué à 9.
en tout cas ce sont les utilisateurs de raspberry pi qui vont être contents…
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
# Typage strict
Posté par Antoine . Évalué à 10.
En lisant cette dépêche je me suis dit « ah, enfin ils abandonnent les conversions automatiques catastrophiques », et puis :
PHP sera toujours PHP…
[^] # Re: Typage strict
Posté par rogo . Évalué à 8.
Oui, PHP est un assemblage douteux et un langage incohérent, et ça ne risque pas de changer, c'est le piège de la compatibilité ascendante. S'ils n'avaient pas fait ce choix, cela aurait obligé les bibliothèques PHP à maintenir deux versions de leur code en parallèle, et l'adoption du typage strict n'aurait probablement eu aucun succès dans la communauté PHP. L'exemple de Python3, pas encore majoritaire dix ans après sa conception, leur a fait peur.
Un cas pratique pour être clair. J'ai un code qui utilise SwiftMailer pour les envois de mails. Si cette bibliothèque passait au typage strict et que je mettais à jour les dépendances de mon code, ça ne casserait rien dans la configuration actuelle. Sans ce typage strict à la demande, je risquerais d'avoir des erreurs à l'exécution un peu partout, avec beaucoup de travail pour migrer. Quand on lit des INT via du SQL, on récupère du texte, et il faudrait faire des typecast systématiques.
[^] # Re: Typage strict
Posté par pascalc . Évalué à 8.
HTML 5 est aussi douteux par rapport à XHTML, Javascript a un système de types encore plus bizarre que celui de PHP (et 'use strict' c'est quand même bien similaire à declare(strict=1) dans PHP). Et pourtant, malgré leurs défauts ce sont ces langages qui dominent le web et de très très loin, tout simplement parce qu'ils sont pragmatiques et qu'ils permettent à tous de créer pour le web. Le web ne migrera pas à Haskell ou autre langage "pur", même s'il y aura de plus en plus de langages qui correspondent à la résolution de problématiques serveur spécifiques, je suis ravi que l'élitisme (dans le plus mauvais sens du terme, qui est de faire tout ce qui est possible pour que ceux qui ne font pas partie du "sérail" de l'informatique pro) ne soient pas gagnants et que la création sur le web reste le plus ouvert possible au plus grand nombre. De manière générale, je ne comprends pas comment on peut détester un langage au point de perdre son temps à le basher partout sur les news le concernant, personnellement par exemple je n'aime pas Python, je suis un hérétique, j'en fais au boulot quand je suis forcé et je reconnais ses qualités, mais ça ne m'amuse juste pas de faire du Python ou du Django. C'est pas pour ça que je vais aller sur tous les posts concernant les nouveautés de Python pour par exemple regretter que les scripts que j'ai écrit en Python il y a 2 ans ne marchent plus en Python 3 alors que des scripts que j'ai écrit en PHP il y a 10 ans marchent toujours en PHP 7 et rendent le même service à leur utilisateurs. Certains d'entre nous veulent faire du code pour répondre aux besoins de vrais utilisateurs et cela à long terme.
Ceux qui n'aiment pas PHP ont plein de choix aujourd'hui pour utiliser des langages qui leur semblent plus cohérents/propres/religieusement casher pour faire des applis web, mais toujours taper sur PHP sur des points de détail, franchement, c'est puéril. PHP est là sur le long terme, l'écrasante majorité du web est en PHP, ce sont des milliards de lignes de code, ça ne changera pas du jour au lendemain et ce n'est pas parce que PHP existe et évolue en bien que ça nuit aux autres langages.
De la même manière, la syntaxe et la grammaire du français, de l'anglais et de toutes les langues dans le monde sont complètement dinques, et pourtant le monde ne parle pas en esperanto, un langage bien propre, bien pur, sans aucune incohérence, le monde doit être très con de préférer des langues compliquées à des langues bien conçues à la cohérence parfaite comme l'Esperanto ou le Volapük…
[^] # Re: Typage strict
Posté par richardd . Évalué à 1.
Cette puérilité est fatigante. Je rajouterais que depuis PHP5 et encore plus à partir de 5.3 et 5.4, il est possible de faire facilement du code très propres en PHP et qui fonctionne toujours.
Bien souvent les critiques sont dûs à des méconnaissances du langage… PHP est un langage qui a toujours évolué en essayant de répondre aux besoins de ses utilisateurs.
Et depuis l'échec de PHP6, il y a une véritable écoute de la communauté, qui s'est professionnalisée, qui est maintenant au cœur des décisions, il suffit de lire les messages sur les mailings lists de PHP, les commentaires et les pulls requests sur github pour s'en rendre compte.
[^] # Re: Typage strict
Posté par groumly . Évalué à 4.
Le probleme de php, c'est plutot la facilite avec laquelle on peut faire du code crade qui marchotte :)
Bon apres, yen a qui aiment php, et c'est leur droit. On peut effectivement se demander quel est l'interet de transformer php en clone d'un autre language "rigide".
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Typage strict
Posté par téthis . Évalué à 7.
Pourquoi cela devrait-être rigide ?
Prenons l'exemple de Typescript qui permet de rendre Javascript fortement typé. Un des types possibles,
any, indique qu'on prend tout. Pour ajouter de la finesse et éviter de ramasser le tout venant, le langage s'est récemment vu ajouter lesunion typeetintersection typePar exemple, une fonction recevant un nombre ou un tableau de nombres
C'est simple et ça fonctionne bien.
The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein
[^] # Re: Typage strict
Posté par Yth (Mastodon) . Évalué à 6.
Arf, la vie est mal foutue, je préfère largement coder en Python qu'en PHP et je fais plein de PHP au boulot, et très peu de Python ^
Yth…
[^] # Re: Typage strict
Posté par Antoine . Évalué à 10.
Je trouve étonnant que de s'intéresser à des fonctionnalités qui concourent à une programmation plus sûre et plus robuste soit vu comme de l'élitisme. En réalité, s'il y a quelque chose d'élitiste (on peut discuter si l'élitisme est un défaut ou pas…), ce serait plutôt de programmer avec un langage très peu sûr qui requiert une attention de tous les instants.
Et bien sûr on a le droit de ne pas aimer Python. Il y a d'autres possibilités sur le même créneau, comme Ruby.
Quant au fait que PHP soit pragmatique, soit, mais le succès de PHP n'est pas vraiment dû au langage lui-même : mais plutôt à ce que, à une époque, le seul déploiement aisé et répandu (chez les hébergeurs) pour un site Web dynamique était mod_php avec Apache. PHP comme langage n'a guère de qualités, et beaucoup de défauts (que ses concepteurs essaient péniblement de corriger, version après version…).
[^] # Re: Typage strict
Posté par rogo . Évalué à 6.
D'abord, je suis un peu surpris de cette véhémence un peu hors-sujet. Je justifiais le choix de compatibilité de PHP, et remarquais que le langage restait sale, rien de plus. Pas de diatribe contre PHP et ses utilisateurs, d'autant plus que je développe avec PHP.
Ensuite, la comparaison des langages de programmation avec les langages naturels me semble plus que douteuse. Quand on parle en français, on se fiche souvent que les mots soient parfois ambigus ou que la grammaire soit approximative. Une erreur de syntaxe n'empêche généralement pas un texte d'être compris. Quand une loi est ambigüe, c'est aux juges d'extrapoler. On attend plus de rigueur d'un langage compilé.
En pratique, il est possible que des codes écrits il y a 10 ans tournent sur du PHP7, mais si tu as déjà fait du portage d'applications PHP anciennes PHP4/PHP5.1 vers du PHP5.4, ça a dû te laisser de très mauvais souvenirs. Ma troisième — et, je l'espère, dernière — expérience là-dessus remonte à la semaine précédente, et c'est toujours aussi pénible. J'ai maudit les inventeurs de
register_globalsetmagic_quoteschaque minute de ma journée.PHP est bien souvent pratique et efficace, mais on ne peut nier qu'il a des défauts énormes. Une typo dans une variable ou une fonction, et c'est le risque de bug à l'exécution. Et même en typage strict, il faut faire une confiance limitée à la vérification des paramètres d'appel. J'aurais aimé que le code suivant déclenche une erreur, dans l'idéal dès la compilation :
[^] # Re: Typage strict
Posté par pascalc . Évalué à 3.
Donc ta logique c'est que PHP c'est sale initialement et que puisque le langage s'améliore avec le temps et qu'il faut refactoriser du code d'il y a 15 ans pour enlever des trucs sales qui ont disparu depuis des années du langage, PHP est sale parce qu'il s'améliore et donc te force aujourd'hui à coder plus proprement ? Donc quoi que fassent les devs de PHP, avec cette logique, c'est mal, autant dire que tu souhaites que le langage n'évolue pas pour ne pas avoir à faire évoluer du vieux code. Au passage, migrer une appli d'une version non supportée depuis une dizaine d'année à PHP 5.4 qui n'est plus non plus supportée, c'est pas très malin, l'effort de portage vers 5.6 aurait été le même et bien plus pérenne. Et si on prend la même échelle de temps entre PHP 4 et 5.4, migrer une appli Python 1.6 à 3.2 ça se fait sans douleur peut-être ? Est-ce même faisable par rapport à PHP ?
[^] # Re: Typage strict
Posté par rogo . Évalué à 2.
Application écrite en 2004 sous RedHat 4 (de mémoire PHP 4.3, en tout cas PHP 5 n'existait pas encore), à migrer sous RHEL7 (sortie en 2014, PHP 5.4). Ça fait 10 ans d'écart.
[^] # Re: Typage strict
Posté par Nicolas (site web personnel) . Évalué à -1.
Pour compléter la remarque de Pascal. Si en 2004 php5 existait. Et s'il est difficile de migrer de php4 à php5 (aux incompatibilités du langage liées à la montée de version majeure), c'est que l'application en question était déjà écrite salement. Cela a toujours été une très mauvaise pratique d'utiliser register_globals. Forcément en raisonnant comme ça, ça complique les choses ; c'est le moins qu'on puisse dire. Mais le problème est-il réellement lié au langage ?
[^] # Re: Typage strict
Posté par Antoine . Évalué à 8.
Le langage a longtemps proposé des fonctionnalités qui étaient de mauvaises pratiques (et il faut se souvenir que
register_globalsa longtemps été activé par défaut chez beaucoup d'hébergeurs), mais le problème ne serait pas lié au langage ?(on peut se rappeler aussi les catastrophiques
magic_quotes…)[^] # Re: Typage strict
Posté par G.bleu (site web personnel) . Évalué à 8.
Et j'ajouterai la nouvelle faille à la mode avec la montée en puissance de mongoDB
http://www.example.com?username=user&password[$ne]=dummy
Magie de PHP, $_GET['password'] va retourner un tableau array("password" => array('$ne' => "dummy")
Ce qui fait donc une requête dans mongodb pour trouver l'utilisateur user n'ayant pas pour mot de passe dummy…
voir http://php.net/manual/fr/mongo.security.php
[^] # Re: Typage strict
Posté par Chris K. . Évalué à 2.
Magnifique en effet .
Une bonne règle à retenir est de ne surtout jamais faire confiance aux entrées fournies par le navigateur sans avoir vérifié qu'elle soient bien conformes à ce que l'on attend.
[^] # Re: Typage strict
Posté par Jérôme FIX (site web personnel) . Évalué à 2. Dernière modification le 15 décembre 2015 à 21:33.
Ces « conseils » sont serinés depuis… euh… toujours ! MongoDB, MySQL, qu'importe l'usage ensuite, on ne fait jamais confiance aux données fournies par l'utilisateur.
Concernant register_globals, l'usage en est déconseillé depuis les débuts de PHP (au moins depuis l'apparition de Supers globales HTTP_*_VARS… elle même dépréciées au début de PHP 4 (4.1 - 10 December 2001).
Elles sont désactivées par défaut depuis la version 4.2 (22 April 2002).
Ensuite si les devs ne lisent ni ne s’intéressent pas aux docs, ce n'est pas non plus que la faute au langage.
[^] # Re: Typage strict
Posté par xcomcmdr . Évalué à 2. Dernière modification le 15 décembre 2015 à 21:43.
"Sanitize your inputs" ?
Euh ouais, c'est mission impossible. Il faut vérifier si c'est pas du SQL, du html, du xml, et on a oublié javascript… Bref, impossible de pas en laisser passer.
Plutôt que de vérifer les entrées, fait en sorte que les entrées utilisateurs ne peuvent pas devenir du code executé.
Autrement dit :
Et encore autrement dit :
http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Typage strict
Posté par whity . Évalué à 3. Dernière modification le 16 décembre 2015 à 09:04.
Dans le cas présent (la faille mongodb décrite), j’ai surtout l’impression que ce qui pêche est l’absence de typage fort.
En gros, il faut distinguer plusieurs choses :
- l’entrée est du type attendu : ça ça peut se vérifier dès le départ (ce n’est pas spécifique aux langages faiblement typés, c’est le cas dès qu’il y a usage de variant dans une api)
- l’entrée est au format attendu : là aussi ça peut se vérifier dès le départ (par exemple, une entrée de type « email » correspond bien à une adresse email)
- l’entrée ne va pas faire un truc hostile : ça c’est le problème que tu décris, et je suis parfaitement d’accord avec ta conclusion : la notion de « sanitize your inputs » ne devrait effectivement même pas exister. La solution est d’utiliser une API sûre.
En revanche, dans le cas présent, la blague, c’est qu’on peut créer une requête parfaitement valide, au moyen d’une api raisonnablement sûre, qui ne fait pas du tout ce qu’on voulait faire et va probablement résulter en une faille applicative.
Et là, la solution est bien de vérifier (≠ sanitize) que les entrées sont correctes d’un point de vue type.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Typage strict
Posté par Chris K. . Évalué à 4. Dernière modification le 16 décembre 2015 à 10:27.
PHP permet tout de même de faire du trans-typage (http://php.net/manual/fr/language.types.type-juggling.php#language.types.typecasting), dans le cas de la faille en question :
va transformer le type tableau non attendu en une chaîne de caractères "inoffensive" (je ne parle pas des failles d'injections / de safe escape dans ce cas) contenant "Array".
[^] # Re: Typage strict
Posté par whity . Évalué à 2.
J’aurais dû être plus clair : mon « absence de typage fort » faisait plutôt référence à l’API mongo db utilisée qu’au langage php lui-même (d’où ma remarque sur les variants). Le typage fort te permet de te passer de la première vérification (la variable est forcément du bon type).
Par contre, le problème est-il spécifique à php ? (ie, c’est un problème de l’API C sous-jacente, ou des bindings php ?)
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Typage strict
Posté par Chris K. . Évalué à 3. Dernière modification le 16 décembre 2015 à 15:35.
La prise en compte des tableaux étant une fonctionnalité de mongo qui permet de construire des requêtes elle n'a pas a être accessible depuis les données postés dans un formulaire donc c'est effectivement un problème de type dans le sens où le type array ne doit pas être passé à mongo depuis un formulaire. D'ailleurs à part pour les Select permettant le choix multiple on a normalement très rarement un tableau en entrée de formulaire, donc les interdire par défaut n'est pas une mauvaise idée.
Alors si c'est bien l'objet de la question, non il n'est pas possible de typer directement le contenu de $_GET / $_POST en PHP.
Du coup même typée statiquement la variable password de l'exemple précédent fait qu'il faudra gérer l'exception TypeError qui sera levée lors de l'affectation. Bon il n'y aura déjà plus de faille de sécurité, juste un script qui plante, c'est déjà mieux.
Par contre écrire une fonction d'abstraction pour accéder aux données de get/post est une bonne pratique et une pratique courante (si vous utilisez netbeans ide par exemple, vous aurez une astuce vous disant qu'accéder directement à ces variables c'est le MAL(tm), à raison).
Si cette fonction est présente l'utiliser pour effectuer un trans-typage automatique est assez trivial.
[^] # Re: Typage strict
Posté par Sébastien Le Ray . Évalué à 2.
C'est là que c'est pas logique… Pour moi il serait plus pertinent d'avoir systématiquement du string en entrée (puisqu'il n'y a pas de typage en HTTP) et de devoir volontairement transtyper si on a besoin de quelque chose d'autre.
[^] # Re: Typage strict
Posté par Chris K. . Évalué à 2.
La syntaxe pour construire des tableaux dans la query string n'est pas propre à PHP, cela fonctionne aussi en Java et dans d'autres langages. En java le typage obligatoire fera qu'il n'y aura pas de surprises sur ce qui sera récupéré.
L'utilisation du typage fort en PHP étant maintenant possible, le même principe peut être appliqué.
Trans-typer en fonctionnant en typage faible pour obtenir le type attendu dans le cadre d'une utilisation normale - un tableau dans le cas d'une liste de sélection à choix multiple par exemple - irait à l'encontre de la logique de typage faible, en tout cas j'y vois tout de même une certaine logique et une fonctionnalité pratique dans la plupart des cas.
La sécurisation des entrées va de toute manière bien au delà de ce problème de typage qui n'est qu'une petite facette des problématiques à gérer, une string n'est pas moins dangereuse si elle est utilisée dans une requête sans être vérifiée.
[^] # Re: Typage strict
Posté par Thomas Douillard . Évalué à 2.
Ben justement, "string" c'est un type fourre tout qui peut contenir n'importe quel langage. Un typage un peu plus poussé forcerait à manipuler des strings pré-parsées … ou des bouts d'AST.
Du coup au lieux de concaténer des strings et de les passer à une fonction qui va l'interpréter comme du SQL, si on a tout simplement pas de fonction qui lancent des requête qui ne font pas d'échappement systématique de toutes les strings raw avant de basculer dans le type "fragment de SQL", par exemple, on a déjà probablement moins de problème vu qu'il faut que le dev s'embête beaucoup plus pour aller se tirer une balle dans le pied …
[^] # Re: Typage strict
Posté par Chris K. . Évalué à 2. Dernière modification le 18 décembre 2015 à 11:05.
D'où le problème "philosophique" pour un mode de fonctionnement en typage faible.
Implémenter ça dans une couche d'abstraction / un framework en utilisant des objets c'est tout à fait possible.
Mais en l’implémentant au niveau des fonctions SQL de PHP on risque de s'embêter beaucoup plus pour faire des choses simples / voulues aussi, pas que pour la balle dans le pied :).
[^] # Re: Typage strict
Posté par Thomas Douillard . Évalué à 3.
C'est avec ce genre d'idées reçues qu'on se trouve des excuses pour pas faire d'efforts dans cette direction ;)
Et à bien y réfléchir, prendre des exemple comme "les fonctions SQL" c'est pas le bon niveau d'abstraction. Il faut réfléchir au niveau "langage hôte" et "langage client" pour proposer des mécanismes au niveau langage. Et regarder ce qui se fait ailleurs, genre Link en C#. https://en.wikipedia.org/wiki/Language_Integrated_Query
[^] # Re: Typage strict
Posté par Chris K. . Évalué à 2. Dernière modification le 18 décembre 2015 à 19:44.
Cela permet surtout d'avoir le choix.
Pour utiliser le système de construction de requête que tu préfères, voir de le construire toi même.
Exécuter une requête par une fonction en lui passant en string la query çà reste une base. C'est peut être trop "bas niveau" pour certains mais complexifier à ce niveau oui c'est pour moi une erreur dans un langage tel que PHP ou de toute manière le langage seul ne permettra pas de gérer un projet sans une bonne base de code et d'outils. En tout cas pas sans exploser les délais. Le tout est de pouvoir choisir ses outils.
Dans ma société on utilise un système de mapping entre les objets et la base de données, il est rare que l'on ait à écrire une requête manuellement en développement et si c'est le cas une classe d'abstraction gère l'aspect sécurité.
Ajouter encore une couche d'abstraction complexe dans le langage n'aurait pas d’intérêt dans ce cas et serait certainement néfaste pour les performances.
Proposer un autre système, en complément du bas niveau, dans le langage ça serait sympa, c'est assez élégant ce qui se fait dans le doc que tu as posté, mais dans ce cas la problématique d'être au courant que ça existe est aussi présente.
En attendant des systèmes d'abstractions pour PHP qui fonctionnent y'en a à la pelle.
[^] # Re: Typage strict
Posté par Thomas Douillard . Évalué à 3.
Mouais ton commentaire me fait penser à une méchante dissonnance cognitive quand même "bon ok, il y a des systèmes élégants et très puissants" … qui font partie du langage, donc qui devraient faire partie de son apprentissage, ce qui résoud le problème de "savoir que ça existe".
Mais : PHP dispose de 10aines de systèmes d'abstractions … dont certains bouts peuvent être considérés comme des palliatifs à l’absence de système élégant intégré au langage, et surtout, je veux faire comme j'ai toujours fait et je suis pas spécialement prêt à repenser mes idées toute faites en y intégrant l'apport du nouveau système élégant :p
Du coup, on peut considérer ces dixaines de systèmes comme un inconvénient qui disperse les efforts de dev avec les devs qui réinventent la roue, et une dispersion des compétences des utilisateurs de ces systèmes qui peuvent être confrontés à plusieurs d'entre eux au quotidien.
Le truc du bas niveau, franchement, c'est probablement un faux problème. Parfois le bas niveau c'est utilisé pour pallier aux faiblesses du haut niveau mal conçu … Les perfs, si c'est une abstraction au niveau du langage, il n'y a pas de raison qu'il y ait une pénalisation par rapport aux abstractions codées dans des libs qui sont la pratique la plus courante, au contraire même, donc non je ne pense pas que ce soit un argument non plus.
et en attendant on a toujours pas réglé le problème de base : le langage rend trop simple l'écriture de code vulnérable et oblige à des compétences pour écrire du code non vulnérable.
[^] # Re: Typage strict
Posté par Chris K. . Évalué à 2. Dernière modification le 20 décembre 2015 à 02:42.
Que ça soit au niveau du langage ou non ce qui va être envoyé au serveur de base de données c'est une chaîne de caractère contenant une requête. La conversion au niveau du langage n'étant pas magique elle a forcément un coût comme toute autre abstraction.
Je ne suis pas un dinosaure comme tu semble le sous entendre, notre système actuel est tout aussi élégant: on gère des des collections, des propriétés, des graphes et différents types de données directement dans le code et cela sans même écrire une seule ligne de SQL.
Créer une propriété ou une collection d'objets stocké en base ne prend qu'une seule ligne de PHP.
On peut le faire car on gère finement la construction de requêtes complexes, parfois récursives ou composées de sous requêtes dans notre couche abstraction. Je ne vois pas l'intérêt d'ajouter une couche d'abstraction à une autre.
Tout cela permet aussi de fortement limiter le nombre de requêtes effectuées, on utilise pour cela un système de cache complexe caché dans cette couche d'abstraction.
Encore une fois, PHP, sans un bon framework, n'offre rien pour gérer de nombreux aspects du développement web : la construction d'interfaces web / templates, les formulaires, la communication ajax/comet, les sessions, l'output buffering, le un système de routage d'url n'existent pas ou ne sont pas évident à gérer sans une (très) bonne connaissance du langage et demandent effectivement une bonne couche d'abstraction pour êtres pratiques à utiliser au quotidien. La base de données n'est qu'un petit aspect du problème et il existe de nombreuses réponses possibles.
Est ce que php est un mauvais language pour autant ? Non car ce n'est tout simplement pas sa vocation : ce n'est pas un environnement de RAD. Les couches supérieures sont maintenues par d'autres projets et offrent du choix.
Si PHP est aussi populaire aujourd'hui c'est aussi certainement car il en existe beaucoup de ces systèmes avec des approches très différentes.
Les compétences seront toujours nécessaires quel que soit le langage, la sécurisation d'un code n'est pas magique.
Ajouter des couches permet de ne pas gérer le problème toi même, ils ne cessent pas d'exister pour autant.
Que cette couche soit directement dans le langage ou dans le framework que tu as choisis ne change pas grand chose au final.
[^] # Re: Typage strict
Posté par Thomas Douillard . Évalué à 0.
J'ai voté inutile parce que j'ai vraiment l'impression que je connais ton discours par coeur et que j'ai justement essayé de le contrer avant qu'il n'arrive. Donc j'arrête là, on a déjà tout dit, désolé.
[^] # Re: Typage strict
Posté par Chris K. . Évalué à 2.
Oui, on est pas d'accord, ce n'est pas grave. Après je te réponds poliment, en argumentant. Si cela t'embêtes effectivement mieux vaut arrêter.
Tu regardes cela d'un point de vue trop théorique selon moi, comme si l'on construisait aujourd'hui une application complète en partant avec comme seule base ce qui est nativement dans le langage.
Dans la pratique cette problématique est gérée depuis (très) longtemps par les framework ou bibliothèques qui te mâchent le travail et t'évitent normalement (même si mongo est dans le cas présent un parfait contre-exemple) de faire trop facilement de grosses conneries.
[^] # Re: Typage strict
Posté par Chris K. . Évalué à 3.
Ah oui point très important sur lequel je n'ai pas répondu pour terminer :
La diversité est une force et non une faiblesse, tout comme dans le LL en général.
Système élégant et puissant ne signifie pas pour autant réponse universelle, surtout dans le cadre d'une problématique aussi complexe que la gestion de la communication avec une base de données et plus spécialement dans le cas de SQL qui possède de nombreuses variantes.
LINQ, par exemple peut poser de nombreux problèmes notamment pour optimiser une requête lorsque tu n'as pas réellement la main dessus.
On déplace la complexité à un autre niveau sans pour autant avoir un contrôle direct dessus. En tout cas bien moins facilement qu'avec une bibliothèque écrite dans le même langage, qui peut être propre au projet, et facilement modifiable à souhait.
Quand on dépend directement de l'interpréteur, c'est tout de même beaucoup moins souple si l'on souhaite étendre le système ou faire la moindre adaptation sur son comportement.
[^] # Re: Typage strict
Posté par Thomas Douillard . Évalué à 2.
Question de niveau d'abstraction. Linq montre qu'on peut avoir des abstractions simples et puissantes.
Mais à l'origine on parlait de langage "hôte" et de langage "clients" histoire d'éviter les collisions de langage, genre garantir qu'une entrée utilisateur ne va pas injecter de SQL dans une requête construite en SQL. La nécessité pour garantir ça n'implique pas du tout qu'on perde en puissance dans l'expressivité de la dite requête construite en SQL résultante, "juste" qu'on soit capable d'assurer la traçabilité des données utilisateurs entre le moment où ce sont de simple chaînes de caractère et le moment ou on les fait basculer dans le monde du SQL. Et qu'au moment de cette bascule, on soit capable d'assurer que ces chaîne entrée utilisateurs ne vont pas se faire interpréter comme des bouts du langage client (SQL dans notre cas) et donc que l'escaping ait bien été effectué.
Ça n'implique pas du tout qu'on fasse perdre des moyens d'optimiser le SQL si on en reste là dans les principes. C'est uniquement parce que le problème est mal dévoupé et qu'on mélange différents niveau/problème qu'on peut perdre à certains autre niveau, ça n'implique pas du tout que ce soit une fatalité de l'abstraction de problème en soit. Au contraire en fait, souvent on abstrait certaines données du problème qui ne sont pas pertinentes pour ce qu'on veut résoudre pour séparer plus facilement les problèmes …
Pardonne moi mais ça c'est encore une bêtise, tu as lu les papiers que cite https://linuxfr.org/news/tex-et-traitement-de-donnees-par-flot-e01-lire-du-tex ? Je te le conseille, tu verrais qu'il existe des langages dont les macros travaillent au niveau de la grammaire du langage de l'interpréteur, ce qui est un niveau d'abstraction assez élevé et pertinent, qui permettent d'offrir énormément de souplesse sans avoir à se battre avec l'interpréteur puisqu'il est prévu pour.
[^] # Re: Typage strict
Posté par Chris K. . Évalué à 2.
Puissance limitée tout de même : LINQ ne gère pas, par exemple, les requêtes récursives en SQL. Donc il va falloir contourner un problème qui n'a aucune raison d'exister si par malheur tu en as besoin. Pour cela et pour les raisons évoquées précédemment ce n'est certainement pas la solution universelle.
Euh oui enfin c'est tout de même toi qui est venu avec LINQ pour exemple et qui propose justement de se débarrasser complètement de la query string SQL pour régler ce problème.
Le problème est bien là : entre ajouter une petite fonction native gérant un sprintf et du safe_escape sur des données typées pour finalement les insérer là où tu veux dans une query string et une intégration au langage comme LINQ il y a un monde et il n'est pas évident de savoir où tu mets le curseur pour définir ce fameux système de sécurisation des requêtes universel qui conviendra à tous les usages.
Mes propos concernaient là encore les manques de LINQ, maintenant tu viens me parler de Tex…
De quelle façon tu comptes te servir concrètement d'un tel système pour gérer la problématique évoquée ?
Je ne suis d'ailleurs pas non plus convaincu, à la base, qu'il soit si pertinent de vouloir mixer deux choses très différentes : un langage de programmation et un langage de requête dans une syntaxe commune qui n'exprime pas clairement ce qui sera envoyé au serveur.
[^] # Re: Typage strict
Posté par Thomas Douillard . Évalué à 1.
Euh, t'es sûr que tu répond à mon commentaire ?
[^] # Re: Typage strict
Posté par Chris K. . Évalué à 2.
Non mais c'est une blague… Je te pose des questions tout de même assez précises pour avoir une idée dont devrait fonctionner ton système merveilleux et tu te contente de me balancer des liens sur le fonctionnement de tex.
Si pour toi il est si facilement possible de faire mieux que ce qui existe, c'est que tu as bien une idée sur la façon dont l'abstraction devrait fonctionner dans le langage en dehors du type fragment sql / chaine non sécurisée quand les données proviennent de l'entrée utilisateur dont tu nous as parlé non ?
[^] # Re: Typage strict
Posté par Thomas Douillard . Évalué à 2.
Désolé, j'aurai du être plus précis dans ce que je voulais évoquer : je parlais en l'occurence de la possibilté d'étendre le langage avec des "macros syntaxiques" : http://ojs.statsbiblioteket.dk/index.php/brics/article/viewFile/20151/17772
Ce type de macro permet d'étendre le langage lui même par un système prévu pour à la base. Sinon je dis depuis le début qu'en mélangeant les compétences des différentes communauté on peut très certainement faire un truc bien, pas que j'ai une solution toute faite. Le truc c'est que justement on (enfin une partie de) la communauté des informaticiens a trop le nez dans le guidon pour réfléchir autrement, et que la recherche a un peu de mal à faire sortir ses travaux d'une communauté un peu trop restreinte.
[^] # Re: Typage strict
Posté par Thomas Douillard . Évalué à 1.
N'importe quoi, on utilise juste pas les bonnes méthodes : les méthodes formelles. On apprend à la fac/l'école les notions de différent langage/d'automate de reconnaissance qui font partie des principes de base.
Et on est pas fichu de spécifier l'ensemble des langages qu'utilise une fonction / une librairie, et de faire des outils qui sont capable de te dire que tu utilise une variable qui provient des entrées extérieures que tu refile sans avoir utilisé de fonction de nettoyage au préalable ?
Faut arrêter l'amateurisme d'urgence.
[^] # Re: Typage strict
Posté par xcomcmdr . Évalué à 6. Dernière modification le 16 décembre 2015 à 13:26.
Montre moi la méthode magique qui va transformer n'importe quelle entrée dangereuse (comme une tentative d'injection SQL) en quelque chose d'inoffensif à tous les coups, alors. Prouve moi que le "satizing" du monde PHP est critiqué à tort depuis des années.
Talk is cheap.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Typage strict
Posté par Thomas Douillard . Évalué à 4.
C'est un coup de gueule de ma part qui dépasse largement PHP. Selon moi c'est exactement le même type de scandale qui fait qu'on peut encore avoir des buffers overflow en C alors que c'est une classe de problème largement connue et étudiée, sur laquelle on a tout dit ou presque.
Ce sont des problèmes que la profession devrait prendre à bras le corps, bosser réellement avec des chercheurs sur les spécification des langages et les outils associés. En parsant une entrée en fonction de la grammaire d'un langage, qui devrait être spécifié, on devrait pouvoir avoir une solution générique qui vérifie qu'une chaîne ne s'interprête pas dans ce langage. En typant les variables chaîne pour les annoter avec le langage qu'elles sont supposées contenir, on devrait pouvoir vérifier qu'une fonction qui va générer du SQL ne reçoit pas une entrée qui n'est pas de type "entrée qui est passé par la fonction qui vérifie que la chaîne n'est pas du SQL" …
Sauf qu'on a jamais vraiment su faire parler des chercheurs qui font des langues formelles avec l'industrie sérieusement comme la Méthode_B, les gens qui font des langages comme Haskell ont du mal à parler avec des gens qui font de la vérification … C'est pas les compétences qui manquent. Faut arrêter de se chercher des excuses et se mettre à bosser là dessus sérieusement.
[^] # Re: Typage strict
Posté par xcomcmdr . Évalué à 5.
Ah là c'est intéressant. Merci !
Et le "sanitizing" c'est bien du nawak, merci pour la confirmation.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Typage strict
Posté par barmic . Évalué à 4.
Euh… Ce sont des approches différentes du même sujet. Quel est la différence entre inclure ta vérification dans ton système de type et le faire via un outil externe au langage ? Que ces gens explorent des façons différentes de faire ne pose pas particulièrement de problème et les vérifications qu'ils font ne sont pas particulièrement complexe (ce n'est pas du domaine de la recherche - du moins pour les vérifications effectuées -).
Ensuite personnellement hors système de type, ce qu'il me manque au quotidien c'est de pouvoir créer des règles facilement à moi (par exemple, le code de ce fichier n'a le droit d'utiliser que cette méthode de tel autre fichier/module/whatever - comprenons nous bien c'est bien plus sophistiqué que la visibilité
protected/public/privateque l'on trouve partout).Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Typage strict
Posté par Thomas Douillard . Évalué à 2.
bah si c'est encore du domaine de la recherche puisque des trucs qui pourraient être assurés par le compilo sont d'énormes sources de failles de sécu, c'est un non sens. Et dire que ça ne concerne que PHP c'est se fourrer le doigt dans l’œil.
[^] # Re: Typage strict
Posté par whity . Évalué à 3.
Le problème est que dans beaucoup de cas, c’est non décidable par un processus automatisé.
Par exemple, phpmyadmin permet de saisir des requêtes sql arbitraires. Et c’est voulu. Et ces requêtes peuvent totalement démolir la base de donnée.
Pour un outil d’analyse, faire la différence entre un processus normal et voulu qui peut péter la base de données en raison d’une entrée utilisateur, et un processus qui ne voulait pas faire ça au départ mais se retrouve à le faire à cause d’une entrée utilisateur malicieuse, est extrêmement complexe.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Typage strict
Posté par Thomas Douillard . Évalué à 2.
Nan mais qu'on sorte pas le cas de PHPmyAdmin pour parler du cas de l'immense majorité des applications qui sont des applis front-end pour lesquels il faut pas laisser l'utilisateur accéder directement à la BDD des comptes bancaires :)
Oui il faut pouvoir débrancher les automatismes de vérif en cas de besoin, mais le cas "par défaut" c'est qu'il faut pas laisser passer les cas ou la vérif n'est pas faite.
On cause de ça depuis tout à l'heure, et on est en train de dire que c'est certainement pas infaisable, voire pas si compliqué, peut être même démontrable mathématiquement si tu utilises des techniques … déjà connues. Le scandale justement à mon avis c'est que ce ne soit pas fait.
[^] # Re: Typage strict
Posté par barmic . Évalué à 3.
Non. Pour toute une classe d'erreur que l'on est capable de vérifier statiquement ce n'est pas une question de recherche, mais d'implémentation/industrialisation. Ce n'est pas parce que tu ne l'a pas en standard dans ton compilateur/interpréteur/jit que la théorie n'est pas déjà formalisée :-)
Ce qui est possible c'est que l'extraction d'invariants dans ton langage soit très complexe.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Typage strict
Posté par Thomas Douillard . Évalué à 2.
Quelque part si l'industrialisation n'est pas faite, c'est un problème aussi pour la recherche. Il y a sûrement des questions à se poser sur ce qui coince.
[^] # Re: Typage strict
Posté par barmic . Évalué à 4.
Avant de chercher à faire une grande table ronde de la sécurité des langages, il faudrait probablement regarder les concepts déjà connu, avant de tenter de réinventer je ne sais quoi.
Regarde, le C existe depuis des dizaines d'années et on commence tout juste à avoir des outillages simples qui permettent de manipuler le langage avec llvm sans passer par un gros hack d'un énorme projet. C'est un pas super important pour pouvoir faire évoluer les choses pour le C et le C++ sans avoir à passer par les comités de standardisation. Faire ce genre d'outil n'a rien de compliqué (particulièrement pour le C) pourtant ça n'existait pas (ou ça n'était pas popularisé).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Typage strict
Posté par Thomas Douillard . Évalué à 2.
Euh, tu sais le but de faire des tables rondes c'est justement de partager les expériences pour pas réinventer la roue :)
[^] # Re: Typage strict
Posté par Nicolas (site web personnel) . Évalué à -3.
Quel que soit le langage, tu peux tomber dans des pièges tels que register_globals ou magic_quotes en PHP. Mais ces pièges n'attrapent que les débutants. Je ne nie pas que ces paramètres étaient des mauvaises idées mais je maintiens que le problème n'est pas le langage pour ces cas là mais celui qui se prend pour un développeur mais qui n'en est pas un.
[^] # Re: Typage strict
Posté par flan (site web personnel) . Évalué à 7.
Ah bon ? Je ne vois vraiment pas comment faire ça avec Python + Django, par exemple.
[^] # Re: Typage strict
Posté par G.bleu (site web personnel) . Évalué à 10.
Le xkcd de rigueur à propos des choses que "tous le monde sait". Dans notre cas en remplaçant coca/mentos par "faille critique sur ton appli parce que tu n'as pas lu une page paumée dans la doc PHP".
Élitisme quand tu nous tiens…
J'ai tendance à considérer le code plutôt que le développeur, un développeur expérimenté fatigué et avec une deadline
impossiblecourte fera-t-il du meilleur travail qu'un développeur débutant avec du temps devant lui et l'envie de bien faire ?Bref pour moi un bon langage t'empêche de faire des conneries (typiquement en appliquant le principe du moindre étonnement) plutôt que se dédouaner en mode "t'avais qu'à lire la doc, sale n00b !"
[^] # Re: Typage strict
Posté par Antoine . Évalué à 8.
Surtout que la personne impactée ne sera pas seulement le programmeur mais l'opérateur du site Web, ses utilisateurs… Se réjouir de ce bon tour joué au programmeur médiocre est franchement puéril.
[^] # Re: Typage strict
Posté par groumly . Évalué à 10.
J'ai vraiment du mal a voir comment un truc register_globals est meme vaguement possiblr dans un langage comme java, ou en rails/django (mais ceux la je les connais tres mal).
Le probleme la dessus, c'est vraiment pas le developeur, mais la core team qui a eu cette idee debile en premier lieu.
Idem sur magic quotes, c'est possible partout, mais c'est une idee horrible quie quiconque avec un demi cerveau fonctionnel ne va pas considerer.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Typage strict
Posté par Chris K. . Évalué à 3. Dernière modification le 15 décembre 2015 à 13:08.
Heureusement les register_globals et magic quotes c'est plus possible, même avec PHP, depuis la sortie de la 5.4 en 2012.
Maintenant en effet c’était un gros piège pourri et ça aurait dû dégager bien avant vu que de toute manière les gens correctement informés ne l'utilisaient plus depuis (très) longtemps.
[^] # Re: Typage strict
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
Oui enfin c'était un paramètre indispensable pour faire fonctionner OSCommerce qui était la boutique en ligne la plus utilisée à l'époque. Les hébergeurs en général ne cherchent pas plus que de faire marcher les trucs populaires out of the box et ce n'est déjà pas une mince affaire.
[^] # Re: Typage strict
Posté par rogo . Évalué à 5.
La version 5.0.0 de PHP est sortie le 13 juillet 2004. Donc en février 2004, au début des développements, PHP5 n'avait pas d'existence officielle. Et les développeurs n'étaient pas assez "élitistes" pour savoir qu'à l'automne un PHP5 arriverait dans leur distribution avec plein d'incompatibilités.
Avant de contre-dire quelqu'un, c'est mieux de vérifier qu'on n'écrit pas une ânerie.
# modules natifs
Posté par David Carlier . Évalué à 3.
Looks good …
Ceci dit pour les développeurs de modules natifs, il va falloir effectuer un bon travail de réécriture, l'API Zend a pas mal change a premiere vue, as encore eu le temps de m'y plonger vraiment.
[^] # Re: modules natifs
Posté par wysman . Évalué à 3.
Pour avoir essayer d'en écrire un moi même, c'est peut être un mal pour un bien !
En PHP 5.x, c'est un gros manque de documentation, d'exemples, des macros incompréhensibles, des macros manquantes (definition de class dans un namespace) …
[^] # Re: modules natifs
Posté par David Carlier . Évalué à 3.
Je suis assez ok pour le manque de docs, fort heureusement le code source de PHP est assez lisible dans l'ensemble.
J'avoue pour mon tout premier module ecrit quelques annees plus tot, ca m'a pris du temps …
Visiblement PHP7 gere beaucoup mieux les allocations memoires, rien que pour ca, ca vaut la peine d'y jeter un oeil ;-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.