Discussion :

[Yogui]

Bonsoir à tous,

Dans un message envoyé aujourd'hui à la liste internals@ de PHP, Rasmus Lerdorf (l'inventeur de PHP) avance des idées afin de permettre aux contributeurs du projet PHP de reprendre le travail.

Pour rappel, la grande nouveauté de PHP 6 est la gestion en natif d'Unicode, ce qui permettrait d'améliorer la chaîne d'encodages (script, source de données, canal de communication PHP/SGBD, fichiers externes tel que XML, document de sortie, canal de communication vers le destinataire du document, etc.). Pour des exemples de problèmes possibles avec les encodages à différents niveaux, voir ici :
http://g-rossolini.developpez.com/tu...concepts#LVI-G

Or PHP 6, qui est actuellement /trunk sur svn.php.net, n'évolue plus assez vite. Les contributeurs se sont lassés et les projets Google Summer of Code n'ont pas suffi. Par ailleurs, des envois de patches à la liste de diffusion laissent supposer qu'il sera nécessaire de créer une branche PHP 5.4 en parallèle du travail sur Unicode (PHP 6.0), et par conséquent PHP 6.0 ne verrait le jour que dans au moins 5 ans... C'est évidemment trop long.

La proposition de Rasmus est de changer d'approche pour gérer Unicode. Il n'est pas nécessaire de continuer dans la voie actuelle, à savoir de réécrire chacune des fonctions du langage PHP afin de leur permettre de gérer Unicode : il y a des alternatives grâce aux extensions intl et mbstring. En conséquence, le langage PHP ne serait pas nativement Unicode mais il aurait la possibilité de gérer les chaînes Unicode. La distinction est subtile, et cela permettrait de gagner quelques années de développement.

Concrètement, afin de permettre aux contributeurs d'appliquer leurs patches sans pour autant les obliger à réécrire leur code pour le rendre compatible avec Unicode, il est proposé pour le repository svn.php.net :

• que /trunk ne soit plus PHP 6.0 mais PHP 5.3
• que PHP 6.0 devienne une branch

Le message de Rasmus : http://marc.info/?l=php-internals&m=126832829512612&w=2


Pensez-vous que cette décision nuise à vos développements à venir ou à l'adoption de PHP ?
Quels problèmes supplémentaires voyez-vous pour PHP à cause de cette décision, si elle est adoptée ? Davantage ou moins de problèmes d'encodage pour vos applications ?

[Thes32]

Bonne nouvelle à priori vu tous ces problèmes d'encodage de tous les jours !

La proposition de Rasmus est de changer d'approche pour gérer Unicode. Il n'est pas nécessaire de continuer dans la voie actuelle, à savoir de réécrire chacune des fonctions du langage PHP afin de leur permettre de gérer Unicode : il y a des alternatives grâce aux extensions intl et mbstring. En conséquence, le langage PHP ne serait pas nativement Unicode mais il aurait la possibilité de gérer les chaînes Unicode. La distinction est subtile, et cela permettrait de gagner quelques années de développement.

si je comprends bien, cette proposition reviens à utiliser les fonctions mb_string dans toutes les entrées/sorties ?
A mon avis cette approche est moins performante qu'une refonte complète.

[Yogui]

Oui, c'est ce que j'ai compris également. Disons qu'il y a deux manières d'ajouter le support d'Unicode à PHP :

• réécrire la totalité des fonctions manipulant des chaînes afin de s'assurer que 100% de ces fonctions puissent gérer les caractères "multibyte"
• améliorer les extensions déjà existantes (mbstring, intl, iconv) pour que l'une d'elles apporte les fonctionnalités manquantes à PHP

Le PHP Group a essayé la première méthode, c'était un doux rêve mais, à l'évidence, cela ne donne pas de bons résultats. Il me semble que la réécriture des fonctions n'est encore effecutée qu'à 70%, après tant d'années :/

Ironiquement, iconv et mbstring ont encore des fonctions non testées ou non compatibles avec Unicode


[Edit] Un message de Stats confirme ce que nous avions compris :

That depends on your definition of "unicode problem". Original definition AFAIK was that you shouldn't care about the encodings anymore and all Unicode stuff (dbs, filesystems, output) will be supported, but it seems to be harder than we thought.

Puis Derick :

intl and mbstring can provide functionality
to deal with UTF 8 string manipulation functions, they can not provide
proper Unicode support. Proper Unicode support is *not* only just
dealing with UTF-8 strings. Proper Unicode support includes dealing with
file streams, with different encodings, with localiztion, with sorting,
with locales, with formatting numbers. Offloading this to extensions
makes Unicode support an add-on hack, and not a language feature. I am
not saying that intl and mbstring aren't *useful*, but they definitely
do not solve "the unicode problem"

[metagoto]

Ils sont quand même bien mal barrés.

Ce n'est pas un secret, bien que peu souvent évoqué, mais au travers de ce problème d'unicode transparait le foutoir sur lequel php est batti, au niveau de l'architecture du code mais aussi du management. Il leur manque un "benevolent dictator" comme cela a été rappelé dans un des posts de la thread sur @internals.

Ce qui est dingue c'est que des années après les premiers travaux sur php6, il y a presque autant d'avis sur ce que doit être "unicode" dans php6 et ce que cela implique, qu'il n'y a de contributeurs.

70% de réalisation pour le projet consensuel initial. C'est déjà pas mal. Même si la motivation est retombée, pourquoi vouloir opérer un shift si radical au point de tout abandonner? Peut être parce que le résultat final n'est pas du tout à la hauteur en terme de perf et de complexité diffusée à tout l'engine, et par conséquence, malheureusement, jusqu'à la moindre extension tierce (à cause d'une très mauvaise API).

Regardons ce que dit Derick un peu plus bas. Derick étant probablement l'un des plus fervents partisans d'un support unicode natif et expert dans le domaine qui plus est:

So I would suggest the following things to do:

- get rid of Jani's play branch
- move trunk to branches/FIRST_UNICODE_IDEA
- put 5.2 in security fix only mode
- pht 5.3 in bug fix only mode
- start adding new features (traits, Ilia's scalar typehint patch,
output buffering things) to the new trunk cloned from 5.3.
- in the meanwhile, start working on patching in back Unicode support,
but in small steps. Exactly which things, and how we'd have to find
out. But I do think it needs to be a *core* language feature, and not
simply solved by extensions. We also need to make sure everybody
understands that Unicode isn't just about encodings, or charsets and
that thre are differences between that. Education is going to be
important (and adding Unicode back in small bits would certainly help
there).

On revient 5 ou 6 ans en arrière... Ces années en partie perdues auraient peut être pu être consacré à un redesign de bas niveau au niveau du core. Voir par exemple ce document: http://wiki.php.net/rfc/remove_zend_api