mageekblog - Mot-clé - utilisateurs - CommentairesLe blog personnel de Frédéric Hardy. Au menu, PHP, agilité, FreeBSD, cuisine et photographies.2021-12-02T08:20:54+01:00Frédéric Hardyurn:md5:26874ca5b8cd4cac8d08b0e68e64f63aDotclearEt si on posait la question aux premiers concernés ? - Laurentjurn:md5:1a8fedd673f2a4fb7c6a0a3c460f7ebc2010-05-19T18:15:58+02:002010-05-19T19:26:55+02:00Laurentj<p>Oui, moi je suis pour supprimer tout les boulets que se traine PHP depuis des années, enlever toutes les incoherences dans les API etc.</p>
<p>Bien sur, faut que ce soit fait dans une version majeure, (PHP6).</p>
<p>Après tout, il y a bien des frameworks qui cassent leur retro compatibilité, voir même qui déclarent compatible uniquement PHP 5.2 ou 5.3, et ça n'a pas l'air, finalement de poser de problème pour les développeurs professionnels.</p>Et si on posait la question aux premiers concernés ? - mageekguyurn:md5:95880a35cf4becb545f4dadc488dfb5f2010-05-19T13:35:31+02:002010-05-19T12:36:10+02:00mageekguy<p>@<a href="http://blog.mageekbox.net/?post/2010/05/18/Et-si-on-posait-la-question-aux-premiers-concernes#c1507" rel="nofollow">Pierre</a> :Il faut que l'on en discute ensemble (et de plein d'autres choses), je t'ai envoyé un mail à ce sujet.</p>Et si on posait la question aux premiers concernés ? - Pierreurn:md5:e52a1a4c5461af1b54e08acbeb90ee522010-05-19T13:31:18+02:002010-05-19T12:33:42+02:00Pierre<p>@fch</p>
<p>elles ne vont pas necessairement etre retirees. Mais l'idee est de choisir ce que l'on veut avoir dans la prochaine release et de voir ce qui est pret ou non. Le gros avantage de cette methode est de reduire le temps necessaire pour une release (5.3 par example a pris beaucoup trop de temps, trop d'additions, trop de changements, incontrollable, pour les developeurs ou les utilisateurs).</p>Et si on posait la question aux premiers concernés ? - mageekguyurn:md5:93fc00473dde50448080875264f2e8942010-05-19T12:27:28+02:002010-05-19T11:46:08+02:00mageekguy<p>@<a href="http://blog.mageekbox.net/?post/2010/05/18/Et-si-on-posait-la-question-aux-premiers-concernes#c1505" rel="nofollow">Pierre</a> : Désolé de ne pas t'avoir reconnu, je n'ai pas l'habitude qu'un core développeur de PHP commente sur mon blog et du coup je suis monté sur mes grands chevaux un peu vite, toute mes excuses, d'autant que Je n'avais pas compris que le trunk ne serait pas la prochaine version de PHP, d'autant qu'il me semble abérrant de mettre des choses dans le trunk pour ensuite les retirer.</p>
<p>Si le but est la simplicité, et tu l'as confirmé, j'ai connu mieux comme stratégie ;).</p>
<p>Quand à Unicode, je connais la discussion dont tu parles sur la liste, mais depuis, c'est le silence radio.</p>Et si on posait la question aux premiers concernés ? - Pierreurn:md5:e36bb1ea75b1a1e10df67c771039e3de2010-05-19T12:21:51+02:002010-05-19T11:33:38+02:00Pierre<p>A propos, c'est moi qui avait supprimer les RG, magic quotes et safe mode durant le dev de php6. Inutile de dire que je suis 200% pour les supprimer, même dans un hypothetique php 5.4 :).</p>Et si on posait la question aux premiers concernés ? - Pierreurn:md5:de21f39ff54868714123864feeecc1d92010-05-19T12:18:55+02:002010-05-19T11:27:24+02:00Pierre<p>@fch</p>
<p>RG n'est pas supprime dans les versions courantes. Et il n'est pas sure que la prochaine version les supprimera, tout depend de quelle version nous allons utilisee (6? plus de RG, si 5.4, les RG resteront).</p>
<p>Concernant UTF-8, nous en avons parle sur la liste (internals), j'ai souleve le probleme de la lenteur d'UTF-16 etant donne que nous devons convertir les donnees un peu partout (99% des libs utilisent UTF-8). Le sujet etait "php6 et unicode" si je me souviens bien.</p>
<p>Il est important de noter que le trunk est maintenant la branche de devolopement. Cela ne veut pas necessairement dire que tout ce qui dans cette branche sera present dans la prochaine release. C'est une tres bonne chose, cela nous donne enfin les moyens de developer php sans contrainte (stabilite des nlles releases, etc.).</p>Et si on posait la question aux premiers concernés ? - mageekguyurn:md5:620aa776aaeed04d1a21b3433a4bbd732010-05-19T12:08:14+02:002010-05-19T11:11:10+02:00mageekguy<p>@<a href="http://blog.mageekbox.net/?post/2010/05/18/Et-si-on-posait-la-question-aux-premiers-concernes#c1502" rel="nofollow">Pierre</a> : Ne t'en déplaise, register_globals ne sera plus disponible dans la prochaine version de PHP, donc Maxime a raison.</p>
<p>Il en va de même pour pas mal d'autres choses.</p>
<p>Quand à l'utilisation de l'UTF8, si tu as des sources fiables, je suis preneur, parce que concernant l'intégration d'Unicode dans PHP, c'est le blackout total de mon point de vue.</p>
<p>Rien ne filtre à ce sujet.</p>Et si on posait la question aux premiers concernés ? - Pierreurn:md5:44154a8aad8d9cf5da01d819c78212e02010-05-19T11:43:08+02:002010-05-19T11:08:09+02:00Pierre<p>@Maxime</p>
<p>Je pense que tu souleves un des gros problemes de PHP: Mauvaise communication et le fait que les utilisateurs ne lisent PAS les changelogs.</p>
<p>Register globals n'est pas supprime, dans aucune des branches actives. Seul trunk (dev tree) ne l'a plus.</p>
<p>PHP 5.3 introduit de nouveaux messages (warning, deprecated), mais la plupart des applications fonctionnent sans probleme, tant qu'elles supportent PHP 5. PHP 4 n'est plus supporte depuis qqs temps deja.</p>
<p>UTF-8: Tu veux dire Unicode et php6? Alors ce sera plutot l'abandon de l'UTF-16 en interne au profit d'une nouvelle solution. Solution qui sera certainement... UTF-8 <img src="/themes/default/smilies/smile.png" alt=":)" class="smiley" /></p>Et si on posait la question aux premiers concernés ? - Maximeurn:md5:5c768707150a3da8ca7f9e2e8c2815fa2010-05-19T10:47:00+02:002010-05-19T10:27:37+02:00Maxime<p>La sacro-sainte retro compatibilité me fait bien rire. Combien de fois a-t-on vu des apps avec des versions php4 et php5 ? Et là avec php5.3, combien d'apps ne tournent pas nativement dessus. Ils suppriment le register_globals, ya pas de retro-compatibilité là ! Faut arrêter.</p>
<p>Déjà que l'abandon de l'UTF8 m'a fortement déçu.</p>
<p>Il y a des choses à changer, autant le faire une bonne fois pour toute, avec le gros flag posé : "ça a changé".</p>
<p>Je pense que s'ils ne font pas cet effort, je lâcherai PHP au profit d'un autre langage. Quand on est dans une logique MVC & Cie, a-t-on encore besoin de ces particularités de php (facilité, code embedded avec le html....) qui nous ont séduites au début ?</p>
<p>(Surtout que pour harmoniser les signatures des fct, une extension peut être mise en place pour retrouver les anciennes signatures.)</p>Et si on posait la question aux premiers concernés ? - Julien Breuxurn:md5:46d95803d8af393a6aeb4e0692cb2efb2010-05-18T21:14:06+02:002010-05-18T20:57:08+02:00Julien Breux<p>Je pense pour ma part que c'est plus que nécessaire !<br />
En effet, rien que la normalisation du nom des fonctions et de leurs arguments...<br />
J'entends beaucoup d'industriels flipper en disant "Et les gars, y'a Python, y'a Python..."<br />
Mais comme justement rappelé ça fait 15 ans qu'on se colle la rétro-compa de PHP et ce qui a fait son succès peut toujours être refait mais amélioré.</p>
<p>Je terminerai sur un mot de la fin ou plutôt deux fonctions de la fin : str_replace / strlen</p>Et si on posait la question aux premiers concernés ? - petitchevalrouxurn:md5:77d9266ac6f9b26afc3249a87ea15a682010-05-18T20:28:09+02:002010-05-18T19:29:33+02:00petitchevalroux<p>Moi je suis carrément pour un changement aussi j'ai pas peur de réécrire mes projets je fais ça en partie quasiment tous les jours :D</p>Et si on posait la question aux premiers concernés ? - mageekguyurn:md5:eaf239a208e13e49542d2d92a1110c792010-05-18T20:27:59+02:002010-05-18T19:29:01+02:00mageekguy<p>@<a href="http://blog.mageekbox.net/?post/2010/05/18/Et-si-on-posait-la-question-aux-premiers-concernes#c1487" rel="nofollow">Trias</a> : j'ai eu le doute également.</p>
<p>J'ai demandé un avis externe et il m'a été répondu compatibilité ascendante.</p>
<p>J'aurais du être plus attentif et réfléchir un peu plus.</p>
<p>Je corrige.</p>Et si on posait la question aux premiers concernés ? - Pierreurn:md5:0a35dc08e06dfc7a409d31553ba0c8112010-05-18T20:27:56+02:002010-05-18T19:29:33+02:00Pierre<p>La question n'est pas de savoir si l'on est pret ou non a avoir un language propre (on l'est tous). Mais de savoir comment on le fait.</p>
<p>De casser la compatibilite d"une API existante est une mauvaise idee, point. Imagine simplement ton code devant traiter les deux (ou plus) cas de figure en fonction des versions.</p>
<p>Mon argument dans ma reponse est de creer une nouvelle API, consistente, reflechie, et propre. Ce qui permet un mouvement en douceur sans ajouter encore plus de confusions ou encore plus de problemes de maintenances.</p>
<p>La derniere chose que PHP a besoin est encore plus de problemes de compatibites entre les versions. A moins bien sure que le but est de faire migrer les applications majeures vers de nouveaux languages ;).</p>Et si on posait la question aux premiers concernés ? - Triasurn:md5:0ec8ad2c98a87bbe2162ece429cffe792010-05-18T19:06:38+02:002010-05-18T19:27:53+02:00Trias<p>Je pense que casser la compatibilité descendante est une chose nécessaire pour un langage qui est devenu si populaire, mais malheureusement qui se traîne des boulets.</p>
<p>L'exemple que tu donne de Python 3 est un exemple honorable, qu'il faudrait suivre, mais qui ne s'applique pas à PHP je pense. En effet, Python est encore assez "jeune", alors que PHP est un vieux de la vieille et ceux qui l'utilisent sont encore assez "frileux". Je vois encore des sites en PHP4 parce que certains n'ont pas voulus faire la migration PHP5.</p>
<p>Si ce choix se fait, il faudrait qu'il soit accompagné de vrais règles de codages.</p>
<p>Je pense que le mieux serait de demander l'avis à la communauté, non seulement sur cette histoire, mais aussi sur des fonctionnalités qui se font attendre (exemple : pouvoir avoir deux fonctions avec le même nom et le même nombre de paramètres mais avec un typage différent). Un peu comme le site ubuntu brainstorming.</p>
<p>En tout cas merci de tes supers articles, je les lis attentivement chaque jour.</p>
<p>PS : Tu parle, je cite de "briser la compatibilité ascendante", pourtant le message cité parle bien de BC "Backward Compatibility".</p>Et si on posait la question aux premiers concernés ? - desfrenesurn:md5:ede281a06206533eb8be1c94fca92fe82010-05-18T14:14:27+02:002010-05-18T13:23:14+02:00desfrenes<p>"des scripts de détection."</p>
<p>cf 2to3 pour un autre langage: <a href="http://docs.python.org/library/2to3.html" title="http://docs.python.org/library/2to3.html" rel="nofollow">http://docs.python.org/library/2to3...</a></p>
<p>ça ne dispense pas de refaire des tests après bien sur.</p>Et si on posait la question aux premiers concernés ? - stfrurn:md5:d4b60a60a5a01f67e78d6dcdd988ab892010-05-18T12:58:16+02:002010-05-18T12:10:31+02:00stfr<p>Entierement d'accord a 200% !<br />
Un jour, faudra bien que PHP se débarrasse de tout les résidus et autres choses débiles qui trainent.<br />
Une doc claire et à jour des changements suffirait pour réaliser cette transition dans les meilleures conditions.</p>Et si on posait la question aux premiers concernés ? - stopherurn:md5:342e85628654a25ba676c237286e43192010-05-18T12:09:08+02:002010-05-18T11:10:31+02:00stopher<p>Complétement d'accord , mais ...<br />
L'évolution d'un langage provoquera forcément des incompatibilités avec des versions antérieures, c'est normal , pour avancer , il faut changer , il suffit de regarder les frameworks qui ont aussi fait ce choix ( par exemple ZF1 => ZF2 ) .</p>
<p>De plus l'on pourrait très bien imaginer une "migration" préparée , tout comme python 2.6 vers 3 , avec l'outil nommé "2to3" qui effectue un travail de traduction , et anticiper les changement avec des warning dans les logs des fonctions incriminées .</p>
<p>Maintenant , je pense que les développeurs de php en ont bien conscience , et prendre une tel décision ne doit pas être de tout repos ...</p>Et si on posait la question aux premiers concernés ? - mikael.randuurn:md5:8cb7f84fe342d984073d829bfb3ad42e2010-05-18T11:40:48+02:002010-05-18T10:46:30+02:00mikael.randu<p>Plutôt pour. Je dirais à 80%<br />
Comme Damien, la solution d'avoir une nouvelle version majeure, complétement réécrite, en se débarrassant des "casseroles", avec une doc complétement réécrite, qui permettrait de professionnaliser encore davantage le langage.</p>
<p>Toutefois, j'espère juste que ça ne cassera pas ce qui a fait la popularité de ce langage, à savoir la simplicité d'entrée</p>Et si on posait la question aux premiers concernés ? - Éric Rogéurn:md5:3a3ddbb48af75c195794623effb163d22010-05-18T11:09:19+02:002010-05-18T10:46:10+02:00Éric Rogé<p>Carrément !</p>
<p>Si briser la rétro-compatibilité peut garantir une plus grande homogénéité et une plus grande logique me semble salutaire, bien sûr que je suis pour.</p>
<p>Et l'industrie a l'habitude de ce genre de pratiques. À un moment ou à un autre, tous les frameworks passent à un moment ou à un autre à une nouvelle version majeure qui casse la rétro-compatibilité.</p>
<p>Bien sûr, tout dépend de comment c'est fait, de jusqu'où ça va et de la fréquence des nouvelles versions qui cassent la rétro-compatibilité (il ne faut pas que ce soit tous les 5 ans non plus)</p>
<p>Mais avec php qui est vieux de plus de 15 ans et dont il faut bien avouer que la syntaxe n'est pas particulièrement sexy, avoir une nouvelle version majeure qui remet les choses à plat , certes on passerait par une période de migration un peu compliquée, mais ça pourrait être salutaire.<br />
Au contraire même, quand on voit avec quelle lenteur php5 a été adopté, celà pourrait être salutaire, ça permettrait de diviser clairement l'univers php en deux.</p>
<p>Ceux qui restent bloqués avec php 4/5 => les vielles librairies, qui sont certes pratiques mais qui techniquement sont à la ramasse (souvent entièrement rédigées en procédural) et qui sont incapables d'évoluer
</p>
<p>Ceux qui sont capable de tourner avec php6 non rétro-compatible => Les projets maintenus, avec du code dont on peut penser qu'il est à priori plus fiable.</p>Et si on posait la question aux premiers concernés ? - Damienurn:md5:a86b9f06e8178dd14265da394c386c7f2010-05-18T10:37:07+02:002010-05-18T09:37:50+02:00Damien<p>prêt à 100% mais sur une version majeure et (j'enfonce une porte ouverte ;)) avec une documentation claire, nette et précise des changements voire un/des scripts de détection.</p>