Discussion :

[RideKick]

Mise à jour du 22.03.2010 par Katleen
Le développement de PHP6 est suspendu, quand reprendra-t-il ?

Après moults déboires, le développement de PHP6 a finalement été suspendu. L'implémentation d'Unicode dans le futur langage devenait un véritable casse-tête technique.

C'est UTF-16 qui avait été choisi pour le support de l'Unicode dans PHP, mais ce développement s'est avéré difficile et la compatibilité très mauvaise.

Le travail est donc mis en stand-by pour une durée indéterminée, le temps de se vider la tête pour les programmeurs, puis de réfléchir à une autre solution pour l'intégration d'Unicode.

PHP6 sera-t-il achevé un jour ? Certainement.

Mais quand ? Mystère.

Source : Message de Rasmus Lerdorf sur le site officiel de PHP

---------------------------------------------------------------------------

Le support de l'unicode boostera l'internationalisation, ce n'est pas un mystère.
Dans PHP6, par défaut, tout sera en unicode à déclaré Andrei Zmievski développeur du cœur PHP a la conférence Zend 2009.

L'unicode permettra donc d'écrire des applications qui pourront jongler entre les différents alphabet et type d'encodage. Au jour d'aujourd'hui il reste encore a développer le support de l'unicode pour les cookies et PDO, une fois terminé il faudra tester PHP6 sur un grand nombre d'applications et de Framework tel que Drupal a déclaré Zmievski said.

La sortie de PHP6 n'est pas encore datée car la plupart des grosses fonctionnalités ont été intégrées à PHP 5.3 qui est sorti en juin dernier (comme le garbage collector pour les objets ou encore le support des espaces de noms).

En ce qui concerne PHP6 il est prévu d'ajouter le support des nombres Long.
Pour les fonctionnalités planifiées nous trouverons : les types scalaires et les propriétés en lecture seule.

Des rumeurs sur PHP7 ont été discutées, beaucoup ont demandés la réécriture du langage mais ce ne sera surement pas le cas car cette proposition a été rejetée par Zmievski.


Source
Attendez-vous PHP6 impatiemment ? Quels seraient les fonctionnalités que vous désireriez y voir ?

[zabka]

Bonjour,

Moi qui suis plus bricoleur que développeur (fraiseur de métier), Je pense que simplifier la prise en charge des langages me simplifiera la vie.
Plus besoin de regarder sur combien d'octet est codé la langue avec accent sans accent, etc.
Comme j'envisage de coder un site avec une langue slave. Je n'aurai plus de problème dans le dtd et dans PHP...

Plutôt impatient, voilà

[Thes32]

Dans PHP6, par défaut, tout sera en unicode à déclaré Andrei Zmievski développeur du cœur PHP a la conférence Zend 2009.

Très bonne initiative à mon avis.

Des rumeurs sur PHP7 ont été discutées, beaucoup ont demandés la réécriture du langage mais ce ne sera surement pas le cas car cette proposition a été rejetée par Zmievski.

Réécrire le langage ? quelqu'un a des infos sur ces propositions ?

[grunk]

J'avoue ne jamais avoir rencontré de problème d'internationalisation (pourtant plus de 6 langues dont le chinois et le russe) tant que tout est en utf8.
Mais si l'unicode peut améliorer les choses et bien tant mieux

Sans réecrire la totalité de php je pense que pas mal de monde aimerait voir arriver un typage fort dans php ou en tout cas moins faible qu'actuellement ^^
Peut être php7

[graphiks]

Bonjour

Un meilleur typage dans PHP peut être vraiment bien pour des applications d'une certaine taille. Ce serai un grand plus.

Par contre, j'espère que PHP ne va pas oublier qu'il est aussi un langage facile à apprendre sans avoir une courbe d'apprentissage trop dur. Le typage automatique actuel de PHP facilite grandement cela.

Sais pas comment comblé les deux, d'un autre côté, faut bien que PHP avance avec son temps

Sky

[rebolon]

Réécriture du code : pas certains que l'on puisse gagner en performance, par contre en lisibilité ce serait un plus. Entre les fonctions "str" qui prennent un "_" ou non. Les paramètres dont l'ordre va changer selon l'humeur du créateur du langage. Il faut avouer, qu'une harmonisation serait la bienvenue.

Concernant le typage fort, quel serait alors l'intérêt de PHP par rapport à du java, du python ou du ruby ? Si on veut des types String, Array ou autre, et bien utilisons la SPL, il y a des objets qui nous permettent de typer nos variables. Chacun est libre de vouloir les utiliser ou non selon son envie, ou selon l'importance du projet concerné.

[Tassin73]

J'avoue ne jamais avoir rencontré de problème d'internationalisation (pourtant plus de 6 langues dont le chinois et le russe) tant que tout est en utf8.
Mais si l'unicode peut améliorer les choses et bien tant mieux

Sans réecrire la totalité de php je pense que pas mal de monde aimerait voir arriver un typage fort dans php ou en tout cas moins faible qu'actuellement ^^
Peut être php7

+1 pour le typage, mais je pense qu'il faudrait laisser au choix entre typage faible ou fort en déclarant le type ou non, mais si on déclare le type on doit le respecter.

Comme exposé ici, le typage faible est l'une des force du PHP.

Moi qui était impatient de voir l'arrivée de PHP6 je vais devoir faire preuve de plus de patience.

[supertonic]

Peut on interpréter par cette news que php n'est pas une bonne base au niveau de son code ?

[pserru]

grunk dit ne pas avoir rencontré de problème d'internationalisation avec l'encodage utf-8. Parcequ'il répond bien au besoin.

Si ci-dessous est une sorte de résumé de cet encodage,
0xxxxxxx +1 [00 0000 .. 00 007F]
110xxxxx 10xxxxxx +2 [00 0080 .. 00 07FF]
1110xxxx 10xxxxxx 10xxxxxx +3 [00 0800 .. 00 FFFF]
11110xxx 10xxxxxx 10xxxxxx 10xxxxxx +4 [01 0000 .. 1F FFFF]
il ressort que l'utf-8 autorise des caractères unicode jusqu'à 21 bits...

Je suppose que le dilème vient du fait que
- l'utf-8 est une solution vraiment très avantageuse (et 100% fonctionnelle aujourd'hui) pour les pays utilisant principalement les caractères romans où les diacritiques sont "relativement rare",
- les ressources nécessaires à la mise en œuvre d'applications traitant de caractères codés sur 16 bits sont importantes, et les fichiers sources doubleront en taille pour les anglo-saxon (en gros)
- l'apport en gain de l'unicode 16 bits pour le développeur chinois (qui n'utilise pas de caractères locaux dans ses "identifiers") est faible, coté source PHP pur. Par contre, il est beaucoup plus significatif pour les sources HTML dont la taille se voit divisée par <~2 à 2,5 environ...

Face à tout ça, je comprends que les développeurs ne se pressent pas, considérant les efforts d'intégration au environnements de développement... Mais ce cela reste à faire.

Je trouve plus intéressant l'idée de refondre PHP qui devrait alors porter un autre nom, pour corriger tous les petits trucs barbants qui le colle au... mais là non plus, ya pas le feu.

[defacta]

---
Des rumeurs sur PHP7 ont été discutées, beaucoup ont demandés la réécriture du langage mais ce ne sera surement pas le cas car cette proposition a été rejetée par Zmievski.
---

Il vaut mieux à mon avis réécrire le langage et viser l'optimisation de l'exécution du code avec encodage automatique des fichiers php au premier lancement de ceux-ci et ré-encodage si modification des fichiers PHP plutôt que de se prendre la tête avec UTF-32 qui ne sera que peu utiliser.

Bien cordialement,
Vincent.

[cedlannoy]

Personnellement je suis ravis d'être passé sous Coldfusion il y a quelques années.
Oui c'est du payant, mais très vite amortie.
Un langage extionnel, bientôt la sortie de Coldfusion 10 et depuis le rachat par adobe, l'evolution du langage est du grand sérieux.

[singman]

J'avoue ne jamais avoir rencontré de problème d'internationalisation (pourtant plus de 6 langues dont le chinois et le russe) tant que tout est en utf8.
Mais si l'unicode peut améliorer les choses et bien tant mieux

Aie ouille, un vrai projet compliqué avec BdD en UTF-8 et tu va comprendre assez vite pourquoi PhP est relativement faible actuellement dans ce type d'application. Je parle notamment des "pièges" pas très évidents, dont tu pourra trouver moult exemples sur Google.

J'avoue que quand on survole le problème, on ne rend pas bien compte de la complexité.

[Aquaa]

+1
Il n' y a pas longtemps je me suis penché sur le développement d'un site en arabe, et j'ai du faire toutes les requetes de recherche dans la base donnés vu que certaines fonctions array_ n'était Unicode.

[vexa]

Bonjour à tous,

Je pense que les problématiques de délais laissent entrevoir un problème de fond plus important.

En partant du constat qu'Il existe à priori deux grandes communautés d'utlisateurs de PHP, les bidouilleurs et les développeurs.

Communauté de bidouilleur drainée par les facilités du copier coller qui marche
et les nombreux outils type CMS où le moindre power user peut monter sa web agency, ceux qui font la démocratisation, la promotion et la multiplication des services informatiques à base de P.H.P..

Communauté de développeur, en demande de professionnalisation de la technologie et des outils, en poussant à titre d'exemple le Zend Framework, les tests unitaires, les nouvelles fonctionnalités du type support unicode, espace de nom, API de service, parce qu'ils ont un réel besoin de ces outils pour simplifier et rendre plus fiable leurs dévelopements pour des demandes de plus en plus complexes.

De là nait une dichotomie profonde dans la communauté PHP.
La première communauté fait la promotion de la technologie pour sa simplicité et son efficacité, la deuxième veut la professionnaliser, la rendre efficace et prouver sa maturité sur des projets de moyenne ou grande taille.
Il ne faut pas oublier Zend qui commercialement vends son expertise, ses solutions d'intégration, ses partenariats, son éditeur et qui clairement
favorise la deuxième comunauté.

Hors en favorisant une des communautés, on défavorise forcemment l'autre car il est à mon sens impossible d'avoir une technologie de base pour grand projet demandant un niveau d'expertise certain qui dans le même temps reste à porter des néophytes.

En faisant le choix du statut quo, PHP restera vu comme une technologie pour petits projets.
Au contraire en "industrialisant", même si je n'aime pas ce terme, c'est celui qu'on rencontre dans la littérature, on referme la communauté avec un PHP qui serait un sous-produit de C# et de Java mais avec dix ans de retard, pleins de bugs, des performances dégradées, des dizaines de bibliothèques en moins et heureusement de manière positive un hébergement moins onéreux, si tant est qu'on puisse qualifier de viable une application boguée et lente tant qu'elle ne coûte pas chère.

Les certifications ZCE et Framework sont là pour trier les appartenances à une des communautés ou l'autre, ce qui en terme de ressources humaines est déjà réglé.

La solution à mon sens serait, dans la mesure où l'importance et l'utilisation du fichier de configuration de PHP commence à être comprises par l'ensemble de la communauté, de proposer deux PHP en un, où les fonctionnalités avancées seraient activées dans le fichier de configuration par les utilisateurs quand ils en auraient besoin.

strict_type = On
namespace = On
unicode = On


On pourrait d'ailleurs proposer d'autres modèles de fichier de conf par défaut :
devPowerUser
devExpert
devCertifiedZCE
devIDontWantToKnowHowButMakeItWorks
ProdIUseMamboChooseTheConfForMe

Et que les applications fourniraient également en plus de leur code leur propre fichier de conf de prod et de dev, ce qui dans la pratique est presque fait avec les assistants d'installation qui vérifient certaines directives de configuration.

Les rétissants me répondront surement en objectant que cela risque d'être un gros bordel en terme de déploiement, j'aurais tendance à dire que pour beaucoup de gens c'est déjà le cas quand ils installent une application.

Pour finir, il me paraît plus simple de faire fonctionner un langage en mode "dégradé" pour les débutants et faire en sorte que l'analyseur ignore certaines instructions plutôt que de former la totalité des bidouilleurs pour en faire des développeurs, surtout que certains ne voudront pas pour diverses raisons que je ne vais pas prendre le temps d'évoquer et que les bidouilleurs de PHP, qui ont tout mon respect, sont à mon sens la force de PHP et qu'en les abandonnant sur le chemin de l'industrialisation, PHP perdrait en premier son âme, puis sa communauté et enfin son marché.


Au passage, comme ce post est un lien dans la newsletter de mars, je tiens à saluer tous mes apprenants à qui je n'ai pas pu dire au revoir et leur souhaite un bon courage pour leurs certifications et j'espère pouvoir le faire de vive-voix quand les choses se seront un peu calmées.


Xavier

[kaymak]

Ce serait une solution que de multiplier les options, mais si c'est pour achever les perfs...

[Schouss]

Je trouve étrange ce choix de l'utf-16 pour php6. le c va plus naturellement vers l'utf-8. Et puis se dire que la mémoire occupé par php va doubler par rapport au php 5 dans des pays utilisant de l'iso-8859-x est vraiment étrange. Pas très écologique de pousser l'utilisateur à l'achat de ram. Aussi, quand on sait que linux a fait le choix d'utf-8 pour cela mais aussi pour la compatibilité naturel de l'iso-8859-x avec utf-8.
L'arrêt du développement est-elle motivé par une remise en cause du choix de l'utf-16 ?

[metagoto]

Je trouve étrange ce choix de l'utf-16 pour php6. le c va plus naturellement vers l'utf-8. Et puis se dire que la mémoire occupé par php va doubler par rapport au php 5 dans des pays utilisant de l'iso-8859-x est vraiment étrange. Pas très écologique de pousser l'utilisateur à l'achat de ram. Aussi, quand on sait que linux a fait le choix d'utf-8 pour cela mais aussi pour la compatibilité naturel de l'iso-8859-x avec utf-8.
L'arrêt du développement est-elle motivé par une remise en cause du choix de l'utf-16 ?

Initialement, utf-16 c'était pour être compatible avec l'encoding utilisé en interne par ICU (la lib sur laquelle php 6 devait se reposer).

utf-8 est préférable car la plupart des librairies/db/services/api supportent cet encoding. php, aurait du de toute manière faire des conversions utf-16 <-> utf-8 pour l'IO. C'était prévu.

Niveau espace mémoire requis, utf-8 est plus compacte pour les langages européens et américain. Pour tout le reste, utf-16 est il me semble et en moyenne, plus efficient. Le plus gros prob de utf-8 est qu'il se prête mal aux opérations sur les chaines. L'index d'un code point ne nous donne pas sa position effective dans la chaine.

En tout cas, le choix reste ouvert actuellement entre utf-8, 16 ou même 32.

[RunCodePhp]

Le plus gros prob de utf-8 est qu'il se prête mal aux opérations sur les chaines. L'index d'un code point ne nous donne pas sa position effective dans la chaine.

Est ce la raison principale du choix de l'UTF-16 ?

Je vais peut être dire une bêtise, mais il me semble que l'UTF-8 n'intègre pas l'intégralité des langues.
Les divers langues Chinoises par exemple (le cantonnais il me semble) est un problème.
L'utf-16 le permettrait, et encore plus l'utf-32.

En somme, leur but n'est il pas d'offrir une internationalisation plus étendue ?
Ca n'a peut être rien avoir ceci dit.



L'intervention de Vexa n'est pas dénuée de bon sens.
Par contre, faut voir si cette question de proposer plusieurs niveaux a déjà été évoquée au niveau de la Team.
Mais offrir plusieurs niveau, ou approche par le biais de config, n'est ce pas plus compliqué encore de le gérer au niveau du langage ?
N'y aurait il pas un risque d'avoir en quelque sorte un langage à 2 vitesses (ou plus) ?
Mais dans une mesure bien moindre, on retrouve un peu ce principe sur la gestion du niveau des erreur, -> error_reporting.
Ceci dit, l'approche est sympathique.


Par contre, vu qu'il est annoncée que le futur Php6 devrait supprimer certaines config au niveau du php.ini, ceci dénote que le langage à un passif qui leur crée des problèmes pour faire évoluer le langage.

En somme, ils sacrifient en partie la compatibilité ascendante que normalement tout langage devrait respecter.
Si pas de compatibilité, une réécriture partielle voir complète du code des sites Web devra se faire.
Vu la situation, ça peu se justifier.


Mais est ce que cette décision de sacrifier en partie cette compatibilité ne serait pas trop timide, insuffisante, ce qui leur vaut une réécriture peut être trop importante pour évoluer dans les temps.
Ne faudrait il pas y aller franchement ?
En profiter pour supprimer une pléiade de fonctions, voir de librairies incompatibles, faire le ménage une bonne fois pour toute.
De même que ne pas obligatoirement offrir une compatibilité entre Php5 et Php6 (encore moins pour Php4) au niveau du langage lui même.
Bref ... éviter de trainer sans cesse comme un boulet toutes les incohérences accumulées depuis des années.

Certes, les développeurs risqueront fort d'être frileux de basculer vers la Php6, mais ça déjà été le cas pour Php4 vers Php5, même à aujourd'hui plein de projets n'ont pas encore fait le grand saut, pourtant, la compatibilité est loin d'être insurmontable.


A mon sens, ils ne veulent pas trop trancher dans le vif, et toujours offrir un maximum de compatibilité, ce qui leur donne la tâche un peu (beaucoup) rude.

[Thes32]

A mon sens, ils ne veulent pas trop trancher dans le vif, et toujours offrir un maximum de compatibilité, ce qui leur donne la tâche un peu (beaucoup) rude.

Tu n'as sûrement pas tord. +32

[Thes32]

Certaines réponses concernant l'internalisation de PHP sont abordés dans ce topic http://www.developpez.net/forums/d89...rojet-unicode/