Cette version à l'air d'avoir la vocation de faire un gros nettoyage et risque de rendre PHP méconnaissable, et beaucoup d'applications heu... à réécrire.
Alors conçernant ta liste de remove : la majeure partie des items (en particulier magicquotes, register globals, register long array etc..) sont des trucs marqués "obsolète" ou déconséillé à utiliser/activer depuis.. la sortie de PHP 4 !
Et tout programmeur serieux est au courant de ces recommandations depuis donc des lustres, et comme ils sont serieux, ils les suivent, et donc ils n'ont pas grand chose à craindre ce passage à PHP6 conçernant ces removes.
Conçernant safe_mode, ça suxor, c'est mal foutu, c'est la galère surtout quand on gère des uploads. Moi je me contente d'open_basedir (qui ne sera pas retiré) et ça fonctionne trés bien
extension mysql: Il va falloir utiliser Mysqli ou PDO
Avoir une API unifié, voilà quelque chose qui va permettre justement une meilleure portabilité du code. Et puis bon, d'ici à ce que PHP6 sorte, tout le monde se sera mis à PDO, et quand php6 sortira, je suis sûr que l'extension mysql sera encore là parce qu'il y aura forcément trop de mécontentant.
Est il vraiment nécessaire de supprimer tout ça ? Ne serait il pas plus bénéfique de changer la configuration par défaut afin de garder une compatibilité avec les applications existantes ?
oui, faut faire le ménage de temps en temps. PHP5 n'a pas assez fait le ménage d'aprés moi. Parce que maintenir trop longtemps des compatibilités avec ce qui précède
- ça complexifie le moteur (bonjour l'apparition de bugs potentiels)
- ça empêche une bonne évolution (garder une compatibilité sur un truc peut empêche une réarchitecture d'un autre truc qui pourtant permettrait de faire des choses encore mieux)
- ça complexifie l'API. ex : avoir deux système de regexp: ereg et preg; un débutant se demande forcément lequel choisir. L'API est suffisement longue comme ça
- c'est aussi la cause de baisse de perf. ex: plus y a de fonctions disponibles, plus le tableau d'index des symboles de fonctions dans l'interpreteur est gros, plus la recherche est longue lors du parsing (c'est une des raisons pour laquelle tous les modules ne sont pas inclus d'office); ou encore, le débutant choisira une fois sur deux cette daube de ereg plutôt que preg pourtant beaucoup plus performant.
# c'est une bonne chose
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal PHP6: Outch !. Évalué à 3.
Alors conçernant ta liste de remove : la majeure partie des items (en particulier magicquotes, register globals, register long array etc..) sont des trucs marqués "obsolète" ou déconséillé à utiliser/activer depuis.. la sortie de PHP 4 !
Et tout programmeur serieux est au courant de ces recommandations depuis donc des lustres, et comme ils sont serieux, ils les suivent, et donc ils n'ont pas grand chose à craindre ce passage à PHP6 conçernant ces removes.
Conçernant safe_mode, ça suxor, c'est mal foutu, c'est la galère surtout quand on gère des uploads. Moi je me contente d'open_basedir (qui ne sera pas retiré) et ça fonctionne trés bien
Avoir une API unifié, voilà quelque chose qui va permettre justement une meilleure portabilité du code. Et puis bon, d'ici à ce que PHP6 sorte, tout le monde se sera mis à PDO, et quand php6 sortira, je suis sûr que l'extension mysql sera encore là parce qu'il y aura forcément trop de mécontentant.
oui, faut faire le ménage de temps en temps. PHP5 n'a pas assez fait le ménage d'aprés moi. Parce que maintenir trop longtemps des compatibilités avec ce qui précède
- ça complexifie le moteur (bonjour l'apparition de bugs potentiels)
- ça empêche une bonne évolution (garder une compatibilité sur un truc peut empêche une réarchitecture d'un autre truc qui pourtant permettrait de faire des choses encore mieux)
- ça complexifie l'API. ex : avoir deux système de regexp: ereg et preg; un débutant se demande forcément lequel choisir. L'API est suffisement longue comme ça
- c'est aussi la cause de baisse de perf. ex: plus y a de fonctions disponibles, plus le tableau d'index des symboles de fonctions dans l'interpreteur est gros, plus la recherche est longue lors du parsing (c'est une des raisons pour laquelle tous les modules ne sont pas inclus d'office); ou encore, le débutant choisira une fois sur deux cette daube de ereg plutôt que preg pourtant beaucoup plus performant.