Discussion :

[ABCIWEB]

Oui au delà de la superstition, je trouve que c'est une bonne idée. Php 6 a déjà existé trop longtemps comme projet, et donc dans les discussions, livres etc. Il ne correspondrait pas à ce qui a été dit puisque certaines fonctionnalités ont déjà été intégrées dans les versions 5.x, et d'autres plus récentes pas encore décrites. Quand il y a trop de différence entre le projet initial et le rendu final, autant ne pas lui donner le même nom.

[Shuty]

Il est vrai que la version 6 de PHP à été très médiatisé et l'échec de cette version a en quelque sorte salie son identité. Au delà des extrapolation avec les autre soft, je trouve l'idée de rename bien.

[IronBibs]

Au final avec ses déboires de version 5.3/5.4, cela parait tellement logique de passer à la version 7 pour que cela soit propre dans les esprits.
Après je peux comprendre qu'il y en a qui ont ce besoin de râler pour tout... C'est pas nouveau

[RyzenOC]

et quand elle sortira cette version ?

[Psyloh]

A 6 ans, on rentre en CP...
Quand on a 6 doigts, c'est qu'on est mal-formé...
Quand t'achète des oeufs par boite de 6, y'en a toujours qui sont cassés...
Quand on meurt on nous enterre à 6 pieds de profondeur...

C'est une constante, je crois ^^

[SurferIX]

Je trouve le choix de PHP 7 cohérent.

Pour cette version j'espère qu'ils vont virer les fioritures qui font perdre un temps fou et se rapprocher de Python qui a une syntaxe vraiment épurée. Comme dit plus haut une normalisation des noms des classes, fonctions, mots reservés et de l'ordre des arguments serait vraiment tip top.

C'est bien pour les développeurs. Mais si on se met à la place des patrons : ça rapporte quoi en plus d'inverser deux arguments et de rajouter / ou d'enlever des "_" ?? Rien.
Des modifications de code pour rester compatible, qui n'aideront en rien à gagner de l'argent sur quelque chose qui tourne déjà.
Même si ça me fait mal de dire ça il faut voir la réalité : enlever la compatibilité c'est problématique, et inutilement coûteux pour les entreprises.

[ABCIWEB]

C'est bien pour les développeurs. Mais si on se met à la place des patrons : ça rapporte quoi en plus d'inverser deux arguments et de rajouter / ou d'enlever des "_" ?? Rien.
Des modifications de code pour rester compatible, qui n'aideront en rien à gagner de l'argent sur quelque chose qui tourne déjà.
Même si ça me fait mal de dire ça il faut voir la réalité : enlever la compatibilité c'est problématique, et inutilement coûteux pour les entreprises.

Complètement d'accord avec toi, à ceci près que je trouve que ce n'est pas mieux pour les développeurs non plus. Etre obligé de modifier des kilomètres de code dans des classes ou codes déjà fonctionnels simplement pour une question de forme serait complètement suicidaire et contre productif. La grande force de php a toujours été la compatibilité maximale entre les différentes versions et cela m'étonnerait qu'ils changent de politique simplement pour faire plaisir aux petits derniers qui croient souvent que le monde commence avec eux (formule imagée pour mieux faire comprendre mais je ne vise personne, que ce soit clair ). Perso cela ne me fait pas mal de le dire, enlever la compatibilité pour ce genre de broutilles serait complètement stupide. Si on doit passer des heures et des heures de mise à jour faut quand même que ce soit pour de meilleures raisons sinon on change de boutique pour un langage plus stable

[SurferIX]

... simplement pour faire plaisir aux petits derniers qui croient souvent que le monde commence avec eux.

[Ah_Kin]

J'espère qu'ils ne feront pas de PHP 13 car ca porte malheur

Pourquoi n'y avait-il pas de gaston 5 non plus? pour les amateurs de franquin.

J'aurais dit que cette histoire d'unicode c'est de la poudre aux yeux mais c'est vrai que c'est le souk. Ça aurait été sympa d'avoir une version 6 pour immortaliser le passage au langage objet possible.

Mais j'aime bien le côté pourquoi faire simple.

[RyzenOC]

es ce que quelqu'un a des infos sur une dates de sortie ? car si sa fait comme la 6, on peut attendre encore longtemps.

[Tsilefy]

Le temps de stabiliser PHPNG, qui semble bien parti pour être la base de la nouvelle mouture.

L'avantage, c'est que PHPNG est déjà existant et fonctionne (relativement) bien, ce n'est pas comme Unicode!

Je dirais un an et demi, deux ans? (source: mon petit doigt). Avec PHP 5.6 pour nous faire patienter entre-temps

[Porkepix]

Complètement d'accord avec toi, à ceci près que je trouve que ce n'est pas mieux pour les développeurs non plus. Etre obligé de modifier des kilomètres de code dans des classes ou codes déjà fonctionnels simplement pour une question de forme serait complètement suicidaire et contre productif. La grande force de php a toujours été la compatibilité maximale entre les différentes versions et cela m'étonnerait qu'ils changent de politique simplement pour faire plaisir aux petits derniers qui croient souvent que le monde commence avec eux (formule imagée pour mieux faire comprendre mais je ne vise personne, que ce soit clair ). Perso cela ne me fait pas mal de le dire, enlever la compatibilité pour ce genre de broutilles serait complètement stupide. Si on doit passer des heures et des heures de mise à jour faut quand même que ce soit pour de meilleures raisons sinon on change de boutique pour un langage plus stable

Rien ne t'empêche de rester sur une version donnée du langage qui te convient.
En attendant, d'autres langages ont eu leurs propres problèmes de cohérence et de choses dont le concepteur du langage s'est rendu compte qu'il s'agissait d'erreurs et qu'il valait mieux changer ça pour en faire quelque chose de plus propre et cohérent, quitte à casser (pas beaucoup mais casser malgré tout) la compatibilité ascendante.
Ça donne quelque chose comme python3 et eux ont été capables de faire le nécessaire, et tu peux me croire qu'ils ont bien fait. En bossant entre les deux versions et bougeant des projets, on se rend compte à quel point celui-ci est nettement plus cohérent.

PHP devrait être capable de suivre la même démarche.

[Tsilefy]

Personne ne conteste que Python 3 est meilleur que Python 2, mais cela fait maintenant 6 ans qu'il est sorti, et combien de temps il a fallu pour que son adoption soit acceptable? Django ne roule sur Python 3 que depuis un an (et en gardant une rétrocompatibilité avec Python 2).

Je me vois mal expliquer à mes clients que pour profiter de nouveaux composants et ne pas rester coincé avec une version en fin de vie (ce qui est le cas de PHP 5.3 actuellement), il va falloir vérifier et modifier tout leur codebase!

La solution qui satisferait tout le monde est l'ajout d'une surcouche tout objet avec une API cohérente. Ainsi, on pourrait faire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

array_push($array, $val)

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$array->push($val)

en même temps.

Pour en savoir plus: http://nikic.github.io/2014/03/14/Me...es-in-PHP.html

[ascito]

A l’époque ou PHP6 à été annoncé comme version supérieur a 5.2 et 5.3 et 5.4, je pensais déjà que le rythme était trop rapide, et perso j'attends tranquillement une version 7 qui soit compatible avec l'ensemble des parcs dev > 5.2; je pense aussi que il y a eu du mouvement sur apache, node, les technos évoluent, les devs aussi, mais ils gardent plus leurs place pendant 10 ans comme à l'ancienne... vive la version 7!!!

[Porkepix]

Personne ne conteste que Python 3 est meilleur que Python 2, mais cela fait maintenant 6 ans qu'il est sorti, et combien de temps il a fallu pour que son adoption soit acceptable? Django ne roule sur Python 3 que depuis un an (et en gardant une rétrocompatibilité avec Python 2).

Je me vois mal expliquer à mes clients que pour profiter de nouveaux composants et ne pas rester coincé avec une version en fin de vie (ce qui est le cas de PHP 5.3 actuellement), il va falloir vérifier et modifier tout leur codebase!

La solution qui satisferait tout le monde est l'ajout d'une surcouche tout objet avec une API cohérente. Ainsi, on pourrait faire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

array_push($array, $val)

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$array->push($val)

en même temps.

Pour en savoir plus: http://nikic.github.io/2014/03/14/Me...es-in-PHP.html

Oui, mais s'il faut que ce soit fait un jour, autant le faire le plus tôt possible, et ce afin d'obtenir un langage plus cohérent, plus simple, plus performant.
Plus ils tarderont, pire ce sera.
Les couches de compatibilité, c'est bien comme solution à court terme, comme passerelle (cf. 2to3, six & co), mais pas sur la durée : ça fait cohabiter deux utilisation qui n'ont rien à voir et coûte des performances du fait de l'ajout d'une couche supplémentaire.

[RyzenOC]

J'ai pas le courage de modifier des kilomètres de code juste pour des broutilles et au final rien m'apporter (5% de rapidité en plus...), surtout si c'est des changements "chiant" comme celui de @Tsilefy.

L'idéal serait de proposer une version de php7 moderne avec de gros changement tout en proposant l'installation d'1 module qui permettrais de garantir une compatibilité avec php5.

Sa me permet comme ca de coder en php7 mes nouveau scripts, tout en faisant fonctionner les anciens.

Je sais pas pour vous mais moi j'en ai marre de réinventée la roue a chaque nouvelle version d'1 langage/Framework.

[1marty1]

J'avais plusieurs scripts et dernièrement plusieurs problèmes rencontrés soudainement. Tout cela pour me rendre compte que PHP et mon fournisseur avaient bloqué certaines fonctionnalités sans avertir. Je pense à me mettre à jour à la version 5.6, mais ceci détruit certains de mes scripts (actuellement 5.2).

Ceci est inacceptable, car j'ai plusieurs clients et je dois tout repenser pour mettre à jour mes scripts. Dois-je me fier envers PHP (en passant à la version 7 ultérieurement).

Par ailleurs, je trouve que PHP offrait un service incomparable sur toutes les plates-formes en termes de fonctionnalités diverses et la sécurité (Je Bloque les mauvais Ip utilisateurs et SPAMS).

Finalement, que me suggérez-vous de faire?

[RyzenOC]

wait and see....

Plus sérieusement je pense que vous n'êtes pas le seul dans ce cas,
Moi ce que je fait (développant et maintenant un intranet) 1 versions sur 2 de php (5.2,5.4, 5.6...) je modifie les kilomètres de code ,sa va assez vite chez moi, 1 journée environ + 1 pour corriger les bugs qui sont apparue.

Puis une fois que sa marche complètement je met ma version en production (et mets a jour PHP)

Je pense attendre php 7.1 avant de migrer dessus, histoire que les premiers bug/problèmes soit corrigée. 1 peut comme pour les OS, on attend toujours le 1er service pack avant de migrer.

[Jarodd]

Tout cela pour me rendre compte que PHP et mon fournisseur avaient bloqué certaines fonctionnalités sans avertir.
[...]
Finalement, que me suggérez-vous de faire?

Changer d'hébergeur

[Paleo]

Ceci est inacceptable, car j'ai plusieurs clients et je dois tout repenser pour mettre à jour mes scripts. Dois-je me fier envers PHP (en passant à la version 7 ultérieurement).

Il faut vendre une maintenance annuelle et non pas seulement de l'hébergement.