14/03/2006 @ 17:03:39: PHP - Que devons nous attendre de PHP6? Une idée?
Alors que nous n'avons pas encore tous digéré le passage à PHP5 et que tout n'est pas encore compatible, l'équipe de PHP prépare tout doucement sa migration à PHP6... Mais que devons nous en attendre?
Tout d'abord, PHP6 devrait enfin supporter l'Unicode, ce ne serait pas un mal en effet pour enfin pouvoir faire des sites multilangues sans trop de soucis.
Ensuite, les fonctions register_globals, magic_quotes et le safe_mode vont disparaître dans PHP6. Ces trois fonctionnalités vont tout bonnement disparaître. On peut comprendre le register_globals et le magic_quotes, le safe_mode lui est plus difficile à avaler. La réponse des développeurs étant que c'est au serveur web d'être mieux sécurisé par le programmeur... Non, on ne s'étrangle pas!
Un cache devrait également faire son apparition en standard dans PHP, ce sera le cas pour APC, que nous pouvons bien évidemment déjà utiliser pour PHP4 et PHP5.
PHP6 s'attardera encore un peu sur l'OO en y ajoutant le support des namespaces, pas plus d'informations sur l'OO qui ne devrait donc pas trop changer sauf sur ce détail.
Finalement, les expressions régulières seront supprimées du noyau PHP pour venir en tant qu'extension et d'autres extensions devraient radicalement changer.
Bref, rien de très extraordinaire pour le moment, à part l'unicode qui ne sera vraiment pas un mal, PHP6 ne devrait s'attarder que sur des modifications mineures qui n'ont pas eu le temps d'être réalisées sur PHP5, et sur quelques améliorations au niveau sécurité et rapidité.
Tout ceci n'est évidemment encore qu'un début et comme d'habitude,... affaire à suivre!
PHP Meeting Notes: http://www.php.net/~derick/meeting-notes.html
Le magic_quotes c'est pas mal chiant aussi
P'tain mais qu'est-ce qu'ils foutent chez PHP ?
Discussion: As safe_mode is a name that gives the wrong signals as making PHP safe, we all agreed that we should remove this function. It can never be made totally safe as there will always be ways to circumvent safe_mode through libraries. This kind of functionality also better belongs in the web server or other security scheme. open_basedir is a feature that we will keep, and we will point users to this functionality in the error message that is thrown when we detect this setting on start-up.
C'est quand même fort
Va donc falloir que nous même on décide de supprimer certaines fonctions (genre le system) et de limiter l'accès de php... Pff...
Plus de magic_quote \o/
Plus de register_global \o/
Des namespaces \o/
Message to PHP dev from ovh : you suck !!!!
ovh>
gizmo> Ces deux fonctions je suis totalement d'accord, le magic_quote est une merde sans nom d'ailleurs, ils ont jamais réussi à ce que tout marche correctement, sa suppression est un bon point... Le safe_mode je suis plutôt sceptique par contre
Finalement, ça m'étonne qu'ovh ne se soit pas suicidé, il gerbe sur tout!
Être dégouté de la vie à ce point, on peut pas faire pire, si?
Haaa haaa j'en veux, j'en veux...
jeezho> Non non, il m'aime, ca suffira
Non mais Ovh, aime bien ce faire plaindre, ctout.
magic quotes youpi !!!! enfin on vire ste merde
pour le safe_mode je suis très très septique.. ca ne va pas renforcer la sécurité chez le premier hébergeur du coin..
et pour l'unicode, enfin !
rapidité? encore plus rapide? c'est possible? déjà coupé à Zend je fais des temps de fou.. si on compare à java ou .net y'a pas photo
ovh>
gizmo> Ces deux fonctions je suis totalement d'accord, le magic_quote est une merde sans nom d'ailleurs, ils ont jamais réussi à ce que tout marche correctement, sa suppression est un bon point... Le safe_mode je suis plutôt sceptique par contre
Disons que ça va peut-être enfin décider les hébergeurs à ne plus utiliser mod_php (même si ça ne t'arrange pas spécialement :o)
Si tu parles de le remplacer par FastCGI ou SCGI pour pouvoir l'exécuter sous un autre user, je suis d'accord sur le principe, mais ces trucs n'ont plus évolué depuis des années et php est incapable de fonctionner correctement en FastCGI.
Donc qu'ils suppriment le safe_mode, à la limite, mais l'alternative sécure n'est absolument pas stable (FastCGI semble très instable) et ne permet pas le quart de la moitié qu'actuellement (du fait de ne pas accepter de tourner en dynamic ni d'avoir de module SAPI correct).
Je veux bien qu'ils poussent vers une séparation serveur web/cgi, mais leur alternative pue gravement des pieds pour le moment
+1
tourner php en cgi
+1
tourner php en cgi
C'est plus sécure et plus finement paramétrable. Pour bien faire, mis à part les modules de base d'apache, rien de devrait tourner en mod.
Oui, mais PHP est pas du tout du tout du tout du tout prévu dans cette optique. C'est le parent pauvre de PHP
C'est plus sécure et plus finement paramétrable. Pour bien faire, mis à part les modules de base d'apache, rien de devrait tourner en mod.
On s'est mal compris..
Je suis 100% pour!
C'est juste la config qui est chaude..
SuEXEC, Droits, CGI, mises à jours de l'executable..
Hum, j'avais pas cliqué sur le lien plutôt, mais c'est un vieux rapport, d'au moins 3 mois
Et La situation sur les namespace n'est pas favorable, ces clinches ne sachant pas vraiment à quoi cela sert ni comment l'implémenter.
Hum, j'avais pas cliqué sur le lien plutôt, mais c'est un vieux rapport, d'au moins 3 mois
Vieux rapport je ne dirais pas, vieille réunion ca oui... J'adore:
Discussion: FastCGI is better than CGI but it can currently be disabled which results in messy code. We will clean up the code and always enable FastCGI for CGI SAPI.
Messy code je ne te le fais pas dire
Vieux rapport, je l'avais lu dans la semaine qui suivit la réunion
Et tu n'as pas fait une news
Pleutre
