Le développement de PHP6 est suspendu, quand reprendra-t-il ? [News]

**metagoto** · 26/03/2010, 08h43

Envoyé par 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 ?

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** · 26/03/2010, 09h54

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** · 26/03/2010, 10h41

Envoyé par RunCodePhp

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** · 26/03/2010, 10h48

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

**metagoto** · 26/03/2010, 10h50

L'analyse de vexa à propos de la fragmentation entre les "industrialistes" et les bidouilleurs (pour reprendre ses termes) est interessante.

Là où je n'adhère plus, c'est la suggestion de fournir "deux" php. Un pour chacune des catégories sus-mentionnées. C'est ridicule.

Si on ne veut pas de namespaces ou de strict typing, est bien on n'y fait pas référence dans les scripts php. Pas la peine d'avoir deux parsers/compilos/runtimes. Qu'il y ait des facilités pour configurer php, OK, et c'est le cas avec les nouvelles features pour le chargement des .ini de config dans php5.3, mais une scission au niveau des spécifications du langage (car ça reviendrait à ça) serait une erreur, en plus d'être ingérable pour les contributeurs de php.

@RunCodePhp

Le choix de utf-16 est lié à la lib ICU qui était préconisée à l'époque pour implémenter unicode dans php6.
utf-8 supporte tout le standard unicode. S'il y a des langages qui posent problème, alors c'est l'affaire d'unicode, pas d'utf-8.

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.

Ils ont déjà tranché dans le vif depuis longtemps. php6 n'est pas sensé être backward compatible avec les précédents php. Parfois à cause détails mineurs, genre la suppression des short open tags <?=.
Non vraiment, leur problème est purement technique.

**pserru** · 26/03/2010, 18h01

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.

**vexa** · 26/03/2010, 21h32

metagoto

Si on ne veut pas de namespaces ou de strict typing, est bien on n'y fait pas référence dans les scripts php

Il se trouve que je me suis mis à faire une mise à niveau technique de AS2 vers AS3 et il semblerait(en première approche rapide) que l'on est obligé de définir des namespaces quand on fait des classes.

J'ai peur que cela arrive dans PHP et que les utilisateurs ne comprenant pas cette notion se mettent à en créer partout sans se douter des futurs implications.

**singman** · 19/04/2010, 21h33

Envoyé par 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

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** · 21/04/2010, 10h32

+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.

**metagoto** · 20/05/2010, 22h40

Les Scalar Type Hints ont fait leur entrée dans le trunk. Il s'agit d'une proposition (et implémentation) réalisée par Ilia Alshanetsky... qui commençait à dater. Finalement, c'est en très bonne voie pour figurer officiellement dans la prochaine version de php.
http://ilia.ws/archives/217-Scalar-T...are-Here!.html
http://ilia.ws/archives/206-Type-hin...g-support.html
http://ilia.ws/archives/205-Type-hin...r-PHP-5.3.html
http://wiki.php.net/rfc/typecheckingstrictonly

**Thes32** · 21/05/2010, 10h38

Les Scalar Type Hints ont fait leur entrée dans le trunk. Il s'agit d'une proposition (et implémentation) réalisée par Ilia Alshanetsky... qui commençait à dater. Finalement, c'est en très bonne voie pour figurer officiellement dans la prochaine version de php.

Bonne nouvelle !

**ETVigan** · 28/05/2010, 08h36

Quel est l'impact pour les classes et la stratégie OOP de PHP 6 ?
Y a t'il quelque part un document disponible sur ce sujet ?
Quid du multi héritage ?

Merci pour l'info

**metagoto** · 28/05/2010, 18h36

Envoyé par ETVigan

Quid du multi héritage ?

Il n'y en aura probablement jamais. Personne ne bosse dessus (du moins au niveau des contributeurs majeurs). Trop complexe à formaliser et à mettre au point. C'est pas dans l'esprit de php.

Le trunk accueil par contre depuis quelques semaines une implémentation des Traits dont la RFC est la suivante: http://wiki.php.net/rfc/horizontalreuse

**defacta** · 21/02/2012, 16h13

---
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.

**Thes32** · 22/02/2012, 14h12

Finalement, le développement de PHP 6 tel qu'il a commencé ne reprendra certainement pas.

La confession de Andrei Zmievski c'est par là http://zmievski.org/files/talks/phpc...-and-php-6.pdf

**stealth35** · 22/02/2012, 14h19

Oui tout ça est de l'histoire ancienne, maintenant on est sur autre cycle de développement

https://wiki.php.net/rfc/releaseprocess

**ETVigan** · 22/02/2012, 14h34

Merci de me noyer sous un flot d'information souvent trop technique pour moi.
Comme je ne sais clore la discussion, je vous demande d'arrêter.

Merci

**stealth35** · 22/02/2012, 15h29

Envoyé par ETVigan

Merci de me noyer sous un flot d'information souvent trop technique pour moi.
Comme je ne sais clore la discussion, je vous demande d'arrêter.

Merci

...

désinscrit toi du sujet

**ETVigan** · 22/02/2012, 15h50

Mais je ne me suis jamais inscrit à aucun sujet...
Et je ne comprends pas cet avalange de post ....
Il y a belle lurette que j'ai posé cette question dans un post, du temps ou PHP6 était encore d'actualité, ce qui n'est plus le cas maintenant me semble t'il ?

**stealth35** · 22/02/2012, 16h26

Envoyé par ETVigan

Mais je ne me suis jamais inscrit à aucun sujet...
Et je ne comprends pas cet avalange de post ....
Il y a belle lurette que j'ai posé cette question dans un post, du temps ou PHP6 était encore d'actualité, ce qui n'est plus le cas maintenant me semble t'il ?

Et alors ? les personnes on le droits de réagir après, je vois pas ce qu'il te choque.