La version 6 de php telle qu'elle nous avait été présenté à été abandonnée . A priori le passage à l'unicode posant beaucoup de problème.

• PHP6, ancien trunk, n'existe plus : il s'agit de la branche FIRST_UNICODE_IMPLEMENTATION
• Le code de PHP5.3 actuel est devenu le trunk, PHP5.3 ne verra plus de nouvelles fonctionnalités : "bug fixes only" (stable code)
• Un 'trunk-dev' va faire son apparition : ca sera la base de PHP5.4 ou PHP6, mais c'est une copy du nouveau trunk (rien à voir donc avec unicode)
• PHP 5.2 est arrêté : il a le statut "security fixes only"

Plus d'infos

J'avais lu ça, et c'est avec grands regrets

Très honnêtement, tout ce qui faisait PHP 6, outre UNICODE, a été introduit avec PHP 5.3.
A part UNICODE, nous avons donc toutes les évolutions qui ont été prévues.

Et comme UNICODE semble compliquer à intégrer, je comprend que la branche PHP 6 ait été abandonnée.

nih? quel interet d'avoir les fonctions unicode de php6? je comprend meme pas l'idée sous-jacente en fait. n'oubliez pas que l'utf8 est une norme en forte progression dans le monde unix et qui ne concerne pas les systèmes windows et mac qui ont déja leur filesystems respectifs qui forcent l'encodage. Avoir des fonctions de gestion de l'utf8 pour la manipulation de chaine oui, mais au dela c'est juste hors-sujet.

http://devzone.zend.com/article/874

Je pense que l'idée était bonne, mais que la migration demandait bien trop de travail, de tests...
Au pire il aurait fallu le faire dès la création, et sinon en effet rester sur l'iso.

De plus je me suis toujours demandé quelles auraient été les impactes de migrations ensuite sur les sites déjà codés avec une version inférieur à PHP6...
Idem, peut-être pas simple a gérer tout ceci, je pense que cela a été abandonné pour toutes ces raisons...

http://devzone.zend.com/article/874

Je pense que l'idée était bonne, mais que la migration demandait bien trop de travail, de tests...
Au pire il aurait fallu le faire dès la création, et sinon en effet rester sur l'iso.

De plus je me suis toujours demandé quelles auraient été les impactes de migrations ensuite sur les sites déjà codés avec une version inférieur à PHP6...
Idem, peut-être pas simple a gérer tout ceci, je pense que cela a été abandonné pour toutes ces raisons...

c'est à peu pres completement faux ce qu'il raconte le monsieur zmievski, ça n'est absolument pas une problématique complexe que de faire du support multi lingue utf8 dans une appli php de nos jours, les seules raisons technique valables d'avoir une extension comme ça c'est si tu as besoin de faire de l'algorithmie avec du texte destiné à l'affichage ou si tu désires coder avec des caractères unicode (genre une variable $héhé), donc un non-sens et une erreur de design manifeste.

d'autre part quand tu dis de rester sur l'iso, je vois pas ce que tu veux dire, l'utf8 est présent pour qui sait le configurer depuis php3 et depuis le début sur linux, l'iso et autre charsets d'antant n'est qu'une erreur pénible dans l'histoire de l'informatique, qui persiste parcequ'on ne sensibilise pas assez les utilisateurs linux/unix (qui je le rappelle sont les seuls concernés) à l'importance d'avoir un charset unique.

La problématique du charset c'est la même que les langues vivantes, ca nous empêche juste de communiquer correctement.

Ok je me suis mal exprimé alors, je voulais dire: rester avec le système actuel, si tu préfères.

Personnellement je trouve cela plutôt complexe moi, mais vue mon niveau de php c'est normal.

Il y a quelques temps, j'ai d'ailleurs tout repassé mon site en iso me demandant pourquoi je m'embêtais avec l'utf-8 car il ne m'apportait rien de plus pour ce que je voulais faire.
En fait il m'apportait plus de soucis qu'autre chose.

J'ai bien dis: pour ce que je voulais faire

l'iso et autre charsets d'antant n'est qu'une erreur pénible dans l'histoire de l'informatique, qui persiste parcequ'on ne sensibilise pas assez les utilisateurs linux/unix (qui je le rappelle sont les seuls concernés) à l'importance d'avoir un charset unique.

La problématique du charset c'est la même que les langues vivantes, ca nous empêche juste de communiquer correctement.

Ca par contre je suis entièrement d'accord.

Par contre, j'ai l'air malin avec ma class maintenant :

if (PHP_VERSION_ID < 60000) {

c'est à peu pres completement faux ce qu'il raconte le monsieur zmievski, ça n'est absolument pas une problématique complexe que de faire du support multi lingue utf8 dans une appli php de nos jours, les seules raisons technique valables d'avoir une extension comme ça c'est si tu as besoin de faire de l'algorithmie avec du texte destiné à l'affichage ou si tu désires coder avec des caractères unicode (genre une variable $héhé), donc un non-sens et une erreur de design manifeste.

Tu code peut-être en anglais, mais ce n'est pas le cas de tout le monde.
Le je modélise un post (dans un forum par exemple) :

Class Message
{
    public $id_sujet; // Identifiant du sujet auquel il est attaché. Type : Integer
    public $id_auteur; // Identifiant de l'auteur du message. Type : Integer
    public $contenu; // Contenu du message. Type : String
    public $publie; // ou publié ; le message a-t-il été publié ou non. Type : boolean
}

C'est un exemple parmi d'autres.
Et le non sens c'est d'avoir un langage ultra-permissif qui limite le jeu de caractère.

PS : Je suis pas agressif

Codage en anglais constamment pour ma part...
Dans le cadre de l'informatique, ca me parait tellement plus simple, sachant que si on développe un projet open-source, la portée doit être internationale et non locale...
Pis l'anglais est quelque peu considéré comme langue officielle en informatique...

tu sais pourquoi on code en anglais kata? la raison c'est justement ça, les charsets, l'anglais est ascii/iso/utf8 sans une seul changement de code pour les caractères. c'est le langage qui est le plus adapté à l'informatique, et faire du code en autre chose que de l'anglais est juste extrèmement dangereux pour la pérénité du code, php était un langage permissif il l'est de moins en moins, et ce n'est pas une contrainte pour php le charset tu peux faire ton code en non utf8 avec des caractères étendus, ca ne te posera aucun problème tant que tu ne changeras pas de système d'exploitation, ou d'éditeur, en revanche si quelqu'un d'autre doit retoucher ton code on peut parier qu'il finira à la poubelle dans 99% des cas.

Il y a quelques années j'avais pris l'habitude que dès que j'étais sur un ordi, j'écrivais en français sans accents...
C'était même rendu au point que j'écrivais sur les forums, chats, commentaires de code comme ceci.
Un jour une amie me dit, il y a une faute ici, pas d'accents, j'explique la raison en gros, elle me répond:
"oui mais bon c'est une faute de français"...
Je réfléchis et je me dis oui c'est vrai, c'est tout sauf une bonne pratique.
Maintenant on pourrait tout écrire en anglais oui, mais on pourrait aussi nous répondre:
"oui mais je ne comprends pas trop l'anglais".

La problématique des charsets ne se limite pas non plus qu'à Php mais aussi aux applications qui communiquent avec, comme SQL...
Mon avis est que l'iso à l'heure actuelle, est le charset le moins problématique sur un serveur mutualisé.

Et on en revient encore à ce que disait :

La problématique du charset c'est la même que les langues vivantes, ca nous empêche juste de communiquer correctement.

tu sais pourquoi on code en anglais kata? la raison c'est justement ça, les charsets, l'anglais est ascii/iso/utf8 sans une seul changement de code pour les caractères. c'est le langage qui est le plus adapté à l'informatique, et faire du code en autre chose que de l'anglais est juste extrèmement dangereux pour la pérénité du code, php était un langage permissif il l'est de moins en moins, et ce n'est pas une contrainte pour php le charset tu peux faire ton code en non utf8 avec des caractères étendus, ca ne te posera aucun problème tant que tu ne changeras pas de système d'exploitation, ou d'éditeur, en revanche si quelqu'un d'autre doit retoucher ton code on peut parier qu'il finira à la poubelle dans 99% des cas.

Tu as raison

tu sais pourquoi on code en anglais kata? la raison c'est justement ça, les charsets, l'anglais est ascii/iso/utf8 sans une seul changement de code pour les caractères. c'est le langage qui est le plus adapté à l'informatique, et faire du code en autre chose que de l'anglais est juste extrèmement dangereux pour la pérénité du code, php était un langage permissif il l'est de moins en moins, et ce n'est pas une contrainte pour php le charset tu peux faire ton code en non utf8 avec des caractères étendus, ca ne te posera aucun problème tant que tu ne changeras pas de système d'exploitation, ou d'éditeur, en revanche si quelqu'un d'autre doit retoucher ton code on peut parier qu'il finira à la poubelle dans 99% des cas.

Tu as raison

Je sais, mais je m'en fiche dans l'absolu, ce qui compte c'est de partager l'information, pas de l'avoir

Hello tout le monde,

<mode etat="passage_eclair">
Mieux vaut avoir affaire au bon dieu plutôt qu'à ses saints....
Monsieur Rasmus nous en parle ici. Pour les anglophobes, faites comme moi, regarder les images (si quelqu'un a la gentillesse de traduire le post de Rasmus, je pense que les anglophobe vous remercieront.

Je pensais que la version 6 n'était pas loin... Il faut encore attendre. Cependant, la patience est mère de toutes les vertus ^^.

Au passage, j'ai lu quelque part (je ne sais plus où) que l'évolution de php6 irait dans ces directions :
* Amélioration de la Programmation Orientée Objet
* Amélioration et sécurisation des fonctionnalités
* Évolution du dépot PECL (bonne nouvelle)
</mode>

Bon code à tous ^^