Il n'y aura donc pas de PHP 4.5, mais le PHP Group continuera à effectuer des mises à jours de sécurité jusqu'au 8 août 2008 si toutefois des failles majeures étaient trouvées d'ici là.
Espérons que cet arrêt du support de PHP 4 encouragera les hébergeurs qui ne l'on pas encore fait à migrer, mais aussi et surtout les développeur d'applications libres écrites dans cette version de PHP à mettre à jour leur code !
Certains diront que la migration d'applications PHP 4 vers PHP 5 ne nécessite pas un gros travail pour le peu que l'on aie codé proprement. Le PHP Group a d'ailleurs mis à disposition des développeurs des guides de migration de PHP 4 à 5, de PHP 5 à 5.1, et de PHP 5.1 à PHP 5.2 (oufff).
Cette annonce coïncide à peu de jours prêt avec la mise en ligne du site GoPHP5, un regroupement de plusieurs grand projets open source PHP visant à pousser les hébergeurs à adopter PHP5 par défaut (sans avoir à passer par diverses manipulation comme l'utilisation de fichiers .htaccess).
Bref, pour les retardataires il reste tout juste un peu plus de 200 jours pour (dé)bogger vos vieux scripts...
Aller plus loin
- Le site de PHP et l'annonce (23 clics)
- Là où tout a commencé... (5 clics)
- L'initiative GoPHP5 et son compte à rebours (4 clics)
- Guide de migration de PHP4 à PHP5 (19 clics)
- Guide de migration de PHP5 à PHP5.1 (5 clics)
- Guide de migration de PHP5.1 à PHP5.2 (7 clics)
# Incompatibilités ?
Posté par mansuetus (site web personnel) . Évalué à 3.
ça fait pas un peu "branleur" de devoir changer les scripts d'un même langage pour suivre les évolutions ?
n'est-ce pas mauvais pour l'image de PHP ? Des décideurs pressés ne vont-ils pas trouver ça bizarre ? Cela ne va-t'il pas à l'encontre de "if it's not broken, don't fix it ?"
IMHO, c'est mauvais pour l'histoire de PHP, ce changement.
Ce message n'est pas un troll : je me demande juste si MARKETING-MENT parlant, ils ont pensé que le marché allait en pâtir...
Je n'arrive pas à trouver de graphs sur l'utilisation du C# Vs PHP... mais je pense que Microsoft saisira l'opportunité pour critiquer les langages "libres".
[^] # Re: Incompatibilités ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 6.
En même temps, elles sont minimes... Et puis c'est pas plus mal de gommer les erreurs de jeunesses non ?
>Pourquoi ne pas avoir renommé l'extension
Ouai, et quand on aura PHP 11.0, il faudra se taper des .php11 ? n'importe quoi.
>ça fait pas un peu "branleur" de devoir changer les scripts d'un même langage pour suivre les évolutions ?
"branleur" ? Donc pour toi, une application, ça ne se maintient pas ? Et ceux qui les maintiennent et qui les font migrer vers d'autres versions du langage ce sont des branleurs ??
>Ce message n'est pas un troll
si si. Y a bien des incompatibilités entre les différentes versions de Java, c'est pas pour ça qu'il est resté dans un placard ou qu'il a mourru hein !
Et puis ce ne sont pas des régressions en passant de PHP4 et PHP5, mais des fortes améliorations. Le modèle objet de PHP3 est totalement pourri, Le modèle objet de PHP4 est limite, et le modèle objet de PHP5 commence vraiment à être bien. Faudra que tu m'expliques, comment, en passant de pourri à vraiment bien, c'est marketing-ment pourri.
>IMHO, c'est mauvais pour l'histoire de PHP, ce changement.
Moi je dis que c'est plutôt une bonne chose, puisque les nouveautés de PHP5 ont permis l'essor de frameworks et autres applis plus robuste et mieux codées.
> mais je pense que Microsoft saisira l'opportunité pour critiquer les langages "libres".
Si ça c'est pas du troll
Franchement ton analyse vaut même pas deux balles.
[^] # Re: Incompatibilités ?
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
Mais bon, je peux me tromper :)
http://about.me/straumat
[^] # Re: Incompatibilités ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
ouai enfin, si c'est deprecated, il faut s'attendre à ce que cela n'existe plus à partir d'une certaine version (enfin en toute logique, je ne suis pas expert java non plus). Donc il faut bien que tu le retouches ton code un jour ou l'autre. En tout cas, j'aime pas laisser des trucs "deprecated" dans mon code, ça fait un peu sale...
[^] # Re: Incompatibilités ?
Posté par fatypunk . Évalué à 5.
Ceci non pas dans le but de te permettre de coder avec d'ancienne méthodes, mais de pouvoir utiliser d'ancien programme sans devoir les recoder... Ensuite si le programme est maintenu tu peux le mettre à jour simplement en ramassant la liste des "deprecated warning" du compilo mais sans jamais provoquer une rupture de validité du code.
[^] # Re: Incompatibilités ?
Posté par Julien Portalier . Évalué à 2.
[^] # Re: Incompatibilités ?
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
Honnêtement, je pense que ça vaut rien du tout par rapport à une solution pour les problèmes de compatibilité.
http://about.me/straumat
[^] # Re: Incompatibilités ?
Posté par BAud (site web personnel) . Évalué à 4.
[^] # Re: Incompatibilités ?
Posté par windu.2b . Évalué à 4.
Bon, les 110ko ne tiennent compte que de la JVM, mais vu qu'il existe J2ME pour l'embarqué, on peut penser que là aussi il y a un gain de place par rapport au J2SE, non?
[1] http://artisan.karma-lab.net/node/61
[^] # Re: Incompatibilités ?
Posté par pw00t . Évalué à 1.
J'ai pas connaissance de devices embarquant le JRE.
Et oui, meme jre6 sur un pc actuel, c'est peanuts :)
[^] # Re: Incompatibilités ?
Posté par BAud (site web personnel) . Évalué à 2.
Sinon, je suppose que ce que tu appelles "PC actuel" ne recouvre pas ceux qui ont encore 256 Mo de RAM (ni même 512) ? C'est tout de même dommage, cela correspond à ce vers quoi tendent les PDA actuellement, avec un processeur encore un peu poussif par rapport aux double/quadruple coeurs "actuels" mais pas forcément par rapport aux processeurs de ce début de siècle, si tu compares http://fr.wikipedia.org/wiki/Pentium_III et http://fr.wikipedia.org/wiki/XScale pour ne citer qu'un constructeur... (je suis ouvert à d'autres comparaisons mais http://fr.wikipedia.org/wiki/N%C3%A9o1973 par exemple évoqué dans la dépêche https://linuxfr.org/2007/07/09/22714.html ne donne pas - actuellement - assez d'éléments de comparaison).
[^] # Re: Incompatibilités ?
Posté par pw00t . Évalué à 2.
De ce que j'en vois sur les devices qui me sont passe dans les papattes au taff, j'ai l'impression (et je dit bien l'impression) que le runtime pour midlet est fourni par le constructeur du telephone et pas par sun.
Ce qui me fait dire ca, c'est les implem' divergentes des differents jsr (sony m'a particulierement emmerde a ce sujet) suivant les telephones et le fait que les gui sont tres differentes d'un telephone a l'autre.
Donc dans cette hypothese, je pense qu'on peut se brosser pour avoir un runtime libre.
Pour la deuxieme question, non, pc actuel ne recouvre pas un P3 256Mo de ram.
Ca c'etait une machine milieu de gamme en 99 (la mienne :-) ).
L'informatique, ca evolue, tres vite et vouloir supporter du matos qui a presque 10 ans au detriment des fonctionnalites me parait une enorme erreur vu la progression du materiel.
Sinon, on est vendredi, donc je glisserai innocemment que java n'est pas gourmand en proco, mais que c'est un vrai gouffre a ram en revanche :-)
J2ME est relativement lourd sur un telephone tout de meme ('fin le temps de chargement de l'appli est assez long je trouve). Cela dit, apres ca se passe plutot pas mal. On fait tourner un triple des dans nos applis, ca se passe tres bien et c'est instantane.
Apres le truc c'est que tu n'utilise pas une appli sur un telephone comme sur un pc: un telephone ca reste (pour l'instant) monotache a l'utilisation, donc en pratique ca marche plutot pas trop mal.
Et puisqu'on est toujours vendredi: quelqu'un veut bien m'expliquer quel est l'interet d'un site https avec un certificat auto signe? (cf tonlien sur linuxfr)
Passque bon, le concept du certif' c'est de le faire signer par une autorite de confiance, si tu signes toi meme ton certificat, ca sert plus a grand chose...
[^] # Re: Incompatibilités ?
Posté par PLuG . Évalué à 2.
je pense que la plupart des sites autosignés veulent activer la crypto.
[^] # Re: Incompatibilités ?
Posté par pw00t . Évalué à 1.
[^] # Re: Incompatibilités ?
Posté par BAud (site web personnel) . Évalué à 3.
[^] # Re: Incompatibilités ?
Posté par pw00t . Évalué à 0.
baleze :-)
Quand au cookie de relecteur, je doute que les moyens a deployer soient en rapport avec le gain :)
Et si t'en es rendu a ce niveau de parano, le certif auto signe, bof bof quoi.
'fin bref j'arrete de troller ma curiosite est satisfaite, merci pour ta reponse. :)
[^] # Re: Incompatibilités ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
- préserver les infos personnelles associées au compte (dont les IP de sessions, l'adresse de courriel, etc.)
- garder l'anonymat ou plutôt le pseudonymat, vis-à-vis de son entreprise ou de son FAI ou du lieu public où l'on se trouve
- préserver le mot de passe utilisé pour ouvrir la session
- éviter que le compte soit utilisé pour des activités illégales (diffamation, propos raciste, etc.)
- parce que faire passer toute l'information non confidentielle en clair, c'est indiquer clairement que tout ce qui n'est pas clair est intéressant
- parce que les intermédiaires techniques entre le site et le visiteur n'ont pas besoin d'en savoir plus sur une visite, sur les goûts du visiteur, sur ses préférences, etc.
- parce que le visiteur peut le faire
- parce que le visiteur est parano
- pour ne pas qu'on sache quel choix le visiteur a fait dans des sondages extrêmement sérieux sur DLFP
...
[^] # Re: Incompatibilités ?
Posté par François B. . Évalué à -1.
A mon avis, Java paye sa facilité d'accès : il est très facile de coder quelque chose qui est lent et qui utilise beaucoup de mémoire.
[^] # Re: Incompatibilités ?
Posté par pw00t . Évalué à 3.
rien que le modele de synchronisation te mange de la ram pour rien.
Ca plus diverses autre choses.
Je suis dev java, j'aime java, java me fait manger le soir, java me paye mes loisirs, java rend mon poil soyeux et mon sexe plus long.
Et pourtant, objectivement, java bouffe de la ram.
Quand a eclipse europa:
http://farm2.static.flickr.com/1003/859185544_dc9fc0ea45_o.p(...)
perso, en 4 ans de dev java intensif, jamais vu eclipse sous la barre des 100mo mini.
Apres, si t'as 3 classes de 20 lignes dans ton projet, aucun plugin, desactive la compile auto etc, je veux bien te croire :)
Cela dit, vu le boulot effectue, j'ai rien a redire la dessus.
Mais pour avoir deja fait de l'eclipse avec 512 de ram... ben tu fais rien tourner a cote.
[^] # Re: Incompatibilités ?
Posté par François B. . Évalué à 1.
De plus, en réaction à la capture d'écran, mon portable ne tourne pas sous windows !
Enfin, non, je n'ai pas installé tous les plugins à la noix et développés avec les pieds qu'on trouve n'importe où sur le net.
Je réitère, eclipse avec moins de 512Mo de RAM c'est faisable. J'avais 192Mo avant, et c'était vraiment trop juste (eclipse 3.0 et 3.1). J'ai remarqué une accélération dans les dernières versions...
[^] # Re: Incompatibilités ?
Posté par pw00t . Évalué à 2.
Si tu connais autre chose pour faire du dev web et debugger une midlet, tu me fait signe.
De plus, en réaction à la capture d'écran, mon portable ne tourne pas sous windows !
Ah ouais? Et alors?
Les objets java prennent moins de bytes sous linux? Marrant, parce que c'est le meme bytecode.
Surtout que vu les perf respectives des jvm linux/windows, j'ai comme qui dirait un gros doute vois tu.
Pour avoir fait tourne la meme version d'eclipse sur la meme machine et les memes projets sous linux et windows, je te garantit sur facture que le plus rapide est tres loin d'etre celui que tu penses.
Sinon, oui, techniquement, c'est faisable.
Pas pour autant que c'est reellement utilisable.
Je suis un grand fan d'eclipse, je l'utilise tous les jours et ne concoit pas de bosser avec autre chose, mais dire qu'eclipse tient raisonnablement dans 50Mo de ram me parait un peu trop partisan :)
[^] # Re: Incompatibilités ?
Posté par Antoine . Évalué à 3.
Marrant, chez moi c'est l'inverse.
[^] # Re: Incompatibilités ?
Posté par Guillaume Rossignol . Évalué à 3.
[^] # Re: Incompatibilités ?
Posté par Yth (Mastodon) . Évalué à 4.
C'est même possible de faire cohabiter les deux dans un même apache. Là par contre tu auras peut-être intérêt à renommer tes fichiers .php qui doivent tourner en PHP4, en fichiers .php4 (et les liens internes aussi), mais c'est un assez moindre effort. Et pas besoin de regarder comment marche l'appli.
Ou alors de configurer apache pour lui dire que dans tel répertoire les fichiers .php sont à envoyer au module PHP4, et là, ya plus rien à changer à ton appli.
Bref, pour répondre au tout premier message, ça semble plus une bonne qu'une mauvaise idée. C'est aussi ça la force du libre : on n'est pas *obligé* de se traîner les boulets des erreurs de jeunesse des logiciels. On le voit bien avec le noyau Linux, il bouge énormément, cassant allègrement des vieilles compatibilités, au final on y gagne bien plus qu'on y perd.
Yth.
[^] # Re: Incompatibilités ?
Posté par astero . Évalué à 0.
Faut comprendre que les pauvres dev sont souvent surchargés et ont autre chose à faire que de se replonger dans des trucs qu'ils n'ont parfois même pas codés.
Et faut aussi comprendre qu'il y a *beaucoup* de situation où la mise à niveau php5 est strictement inutile.
[^] # Re: Incompatibilités ?
Posté par Yth (Mastodon) . Évalué à 3.
Je n'ai *aucune* idée de la réalité, et de l'importance, de cette incompatibilité entre PHP4 et PHP5. Globalement, ça marche pareil. Si on n'a pas de dev sous la main et que ça ne marche pas pareil, on peut bidouiller assez aisément avec apache pour avoir les deux.
Et je pense que dans la majeure partie des cas, il n'y a certes aucun besoin de passer de PHP4 à PHP5, mais aussi aucune difficulté, et que ça marche tout seul...
Alors je dis juste qu'il faut relativiser le problème, je ne crois pas qu'il y ait quoi que ce soit de dramatique...
D'un point de vue personnel, je n'aime pas le PHP, s'il est capable d'évoluer et de se débarrasser de ses défauts, je réviserait peut-être mon jugement, donc j'accueille la nouvelle plutôt bien !
Yth, qui retourne à son python, parce que le python, c'est bon !
[^] # Re: Incompatibilités ?
Posté par astero . Évalué à 1.
Je ne faisait que confirmer vu que quelqu'un a osé te moinsser :)
Par contre je suis pas vraiment sûr que toutes les migrations soient si faciles... par exemple j'ai une appli codée avec register_globals (en gros ça influe la manière dont tu vas récup les données POST/GET) et reprendre tous les scripts un par un serait assez difficile... :/
[^] # Re: Incompatibilités ?
Posté par Kouenny . Évalué à 1.
Pour ce cas précis, tu peux toujours appeler extract($_GET) et extract($_POST) en tout début de script. D'accord, c'est sale, ça ne résoud pas le fait que "register_globals" c'est une chose horrible, mais ça marche !
[^] # Re: Incompatibilités ?
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
C'est le principe des deprecated, on vous bloque pas mais on vous prévient que c'est dépassé ce que vous faites. C'est quand même plus sympa que de flinguer des programmes. PHP aurait du prendre exemple pour le coup.
http://about.me/straumat
[^] # Re: Incompatibilités ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: Incompatibilités ?
Posté par jarodender . Évalué à 3.
De plus d'après mes souvenirs, on associe souvent une version PHP à un ensemble LAMP enterprise, donc cela impose de faire une migration apache, php et mysql, ce qui implique : soit de changer de machine, soit de faire évoluer tous les projets en même temps, car on essaie de faire de la mutualisation sur les serveurs car la virtualisation n'est pas toujours au point. (ou validée)
Donc résumer en disant que PHP5 est sorti il y a 3 = cela a donné le temps de se mettre à jour, ne me semble pas un argument valable pour des décisionnaires d'entreprise qui recherchent à limiter les budgets à tout prix.
Donc pour moi aussi il serait plus agréable de savoir que PHP5 garde la compatibilité avec PHP4, malheureusement ce n'est pas le cas.
J'ai récemment dû faire une migration de ce type (LAMP enterprise), pour un changement de version mineur (pour MySQL je ne suis plus trop sûr des versions) :
- Apache 1.2
- PHP 4.2
- MySQL 4.0
vers
- Apache 1.3
- PHP 4.3
- MySQL 4.1
Et bien ça a pris un certain temps en terme de jours/hommes pour vérifier que tout allait bien se passer (notamment à cause du changement de version de MySQL qui avait des répercussions entre autre sur le type date ...) pour toutes les applications.
J'imagine donc sans mal des problèmes équivalents s'il faut changer Apache 1.3 en 2.0, PHP 4 en PHP 5 et MySQL 4.1 en 5.0, bref y'a de quoi bien s'amuser !!
[^] # Re: Incompatibilités ?
Posté par Yth (Mastodon) . Évalué à 3.
Le service LAMP avec PHP4 et tout un tas d'applis PHP4 dessus, il suffit de le laisser en place, et tout va continuer à fonctionner. Les sources sont (et seront) toujours disponibles. On pourra encore installer un PHP4 dans dix ans, même s'il faudra un Apache 2.2 maxi par exemple, il sera aussi disponible...
Les gens ne sont pas *obligés* de migrer !
surtout s'il s'agit d'un serveur entièrement géré par une entreprise et qu'elle n'a rien à demander à qui que ce soit.
L'idée là c'est plus que les services d'hébergements de pages web, sont incités à passer à PHP5. Dessus il y a majoritairement (j'insiste sur ce mot) des sites persos. Donc des forums, blogs, et cie, qui souvent vont très bien fonctionner en PHP5, pour peu éventuellement qu'une mise à jour soit faite.
En fait, je doute que cette annonce change vraiment grand chose pour les entreprises...
Je peux me tromper.
Yth.
[^] # Re: Incompatibilités ?
Posté par jarodender . Évalué à 2.
C'est un peu comme les systèmes d'exploitation, en entreprise il reste encore des AS400 / MVS / UNIX, mais ces systèmes évoluent encore (je suis pas sûr pour l'AS400) et essaient justement de garder une compatibilité avec les anciennes versions (surtout MVS) pour que les migrations se fassent en douceur (vive IBM)
Donc pour moi dans l'idéal il faudrait :
- soit une version PHP5 compatible PHP4,
- soit fournir les outils pour transformer tout code compatible PHP4 en code PHP5
De toute façon, le problème n'est pas d'améliorer le langage, au contraire c'est une excellente nouvelle, il faut juste trouver le moyen pour que les migrations se fassent en douceur, sinon PHP va avoir une mauvaise réputation (si ce n'est déjà fait). Par exemple quand je discute de PHP avec des experts en sécurité, en général on me rit au nez car pour eux le langage est trop laxiste et de ce fait n'encourage pas à écrire du code sécurisé par défaut (don't feed the troll surtout un vendredi).
[^] # Re: Incompatibilités ?
Posté par Raphaël G. (site web personnel) . Évalué à 4.
Tout dépend comment tu code ton site en php...
Si tu as :
- register_global
- non filtrage des données users
- upload de fichier .php dans un répertoire où le php peux être interprété
- eval a gogo
ton site sera une passoire et fera un très bon shell sur internet.
Par contre si tu code proprement en utilisant :
- register_global off (par défaut depuis php5)
- $_GET $_POST correctement nettoyées, peu de globales
- vérification de type sur les fichiers envoyé (vérifier que ça contient pas .php a la fin, mais ton type demandé)
ton site sera correct et ne devrais pas avoir de soucis niveau sécurité.
Bon après on laisse toujours une faille quelque part, selon le nombre de ligne écris...
[^] # Re: Incompatibilités ?
Posté par Zenitram (site web personnel) . Évalué à 2.
Ah bon?
Laisser une tonne d'applis avec plein de trous de sécurité (puisque PHP4 sera aussi arrêté coté patch de sécurité...)?
Voila un drôle de conseil...
[^] # Re: Incompatibilités ?
Posté par Yth (Mastodon) . Évalué à 0.
* Si tu as des gens pour faire des audits de sécurité, et coder des patchs pour tes applis, alors tu as des gens pour les migrer en PHP5 pour raisons de sécurité. Ce n'est qu'un patch de plus, pas forcément plus difficile à faire qu'un autre (ça reste globalement pareil PHP).
* Si tu ne développes pas l'appli toi-même, mais que tu te contentes de la maintenir à jour, pour raisons de sécurité, c'est elle qui passera à PHP5, pour raisons de sécurité.
Le seul argument qu'il te reste sont les patchs de sécurité PHP4.
Qui sont encore maintenus pour pas mal de temps, un an.
Ca laisse le temps de trouver une solution, si c'est vraiment critique, non ?
Et les problèmes de sécurité de PHP4 sont justement une des raisons de l'existence de PHP5. Donc, si c'est vraiment critique, alors, tu fais l'effort de migrer, non ? Et si ça ne l'est pas et que comme la plupart des gens tu as un PHP4 pas super à jour avec les tout derniers patchs, ça ne changera pas grand chose...
Yth.
[^] # Re: Incompatibilités ?
Posté par Zenitram (site web personnel) . Évalué à 1.
Ca dépend : si une faille est découverte (et ça arrive quand même souvent), l'appli sera sacrément moins sécurisé qu'aujourd'hui, faute de patch de sécurité.
Dire qu'on garde une ancienne appli sur le web non maintenue coté sécurité (non maintenu coté évolution, oui on s'en fout, mais coté sécurité...), c'est pas mal offrir un grand boulevard pour le futur aux crackers.
Oui, il reste un an, mais donc il faut y penser maintenant. Ou alors jouer avec la roulette russe. C'est un choix, faut toutefois en être conscient plutôt que dire un "Ca ne sera pas moins sécurisé qu'aujourd'hui" dépendant de ce que sera le futur...
[^] # Re: Incompatibilités ?
Posté par Yth (Mastodon) . Évalué à 1.
Le trou, il est là, ou il n'est pas là, c'est quand même assez binaire...
Ce n'est pas parce qu'une faille est découverte six mois après la sortie d'un logiciel, qu'elle n'était pas déjà présente au début.
"Ca ne sera pas moins sécurisé qu'aujourd'hui" dépend strictement de comment c'est aujourd'hui.
Yth.
[^] # Re: Incompatibilités ?
Posté par Thomas Douillard . Évalué à 3.
En pratique il y a des trucs qui changent avec le temps, la connaissance de l'appli par les attaquants potentiels, les technos d'attaques, l'environnement logiciel autour, des trucs que tu peux pas forcément imaginer qui font qu'apparaitrons des failles au cour du temps, ou plutôt des moyens d'attaquer ton appli. Peut être même si ton appli pouvait à la base considérée comme sécurisée à la base.
Le tout amha :)
[^] # Re: Incompatibilités ?
Posté par Yth (Mastodon) . Évalué à 2.
Pas moins sécurisé, mais plus aisé d'accès...
Mais ce problème reste plus large, non ? Je veux dire, si une boîte veut assurer la sécurité de son appli, et réagir à toutes les failles trouvées, elle doit entretenir des développeurs pour faire ce travail ?
Ces développeurs peuvent migrer l'appli en PHP5, finalement c'est aussi une correction de failles multiples, non ?
Et si la boîte ne veut pas avoir de devs qui se chargent du bidule, c'est qu'implicitement elle accepte le risque que des failles soient trouvées, mais qu'il sera bien temps de réagir à ce moment là, d'ici là il y a le fameux : « ça marche, on ne touche pas. »
Et si on ne touche pas parce que ça marche, on ne touche à rien, on conserve le serveur sans rien changer, le même apache, le même PHP4, et tout fonctionne comme avant.
En gros l'entreprise elle a deux alternatives : focaliser sur lasécurité et toujours tout mettre à jour, patcher, et corriger. Je pense que là la migration PHP4->PHP5 rentre dans la politique de sécurité, ça fait juste un patch de plus, à mon avis pas extrêmement complexe à faire.
Ou alors se dire « ça fonctionne on ne touche à rien », et là, que le PHP4 soit ou non encore supporté n'a aucune importance : quand on ne touche à rien, on ne touche à rien...
Me trompé-je ?
Y'a-t-il vraiment un cas pratique où l'arrêt du support de PHP4 va réellement causer des problèmes ?
Yth...
[^] # Re: Incompatibilités ?
Posté par Thomas Douillard . Évalué à 1.
Ben ça dépend surtout de la taille du patch, une migration vers une version sensée être compatible ça se passe déjà pas toujours bien, alors une migration vers une version incompatible, c'est pas forcément léger.
Après j'ai pas touché à PHP depuis un bail, donc je sais pas trop ce que ça peut représenter.
[^] # Re: Incompatibilités ?
Posté par tcheuck . Évalué à 1.
Mais c'est pas forcement leurs fautes. Par exemple il n'est pas rare de voir sur des forums des gros malin suggérer de remplacer la balise d'ouverture "<?php" par "<?" pour gagner 0,0000001 sec d'exécution sur un code hyper crade...
C'est en grande partie pour ça que je suis plus ou moins pour la disparition du style "procédural" dans PHP, ce qui obligerais pas mal d'utilisateurs de PHP à réapprendre a coder proprement, et ça serait pas plus mal...
De toutes façons, plus on va monter dans les versions de PHP, plus les scripts codées avec les pieds seront inutilisables.
[^] # Re: Incompatibilités ?
Posté par jmny . Évalué à 4.
[^] # Re: Incompatibilités ?
Posté par Julien Portalier . Évalué à -2.
> plus on va monter dans les versions de PHP, plus les scripts codées avec les pieds seront inutilisables.
Tant mieux.
[^] # Re: Incompatibilités ?
Posté par tcheuck . Évalué à 6.
Si. C'est tout simplement déconseillé, car si y pète a l'administrateur du serveur de basculer "short_open_tag" a "Off", bah du jour au lendemains toutes tes pages qui utiliserons les "short_open_tag" (<?) verrons leurs code source (PHP) affiché à l'écran...
Quand au fait que ce soit plus rapide, peut être pour le dev, oui. Mais c'est comme ne pas échapper ses requêtes SQL, ou utiliser $argument à la place de $_POST['argument'] parce que "register_globals" est activé: ça s'appelle coder avec les pieds.
[^] # Re: Incompatibilités ?
Posté par windu.2b . Évalué à 3.
[^] # Re: Incompatibilités ?
Posté par Gniarf . Évalué à -6.
[^] # Re: Incompatibilités ?
Posté par François B. . Évalué à 2.
[^] # Re: Incompatibilités ?
Posté par Gniarf . Évalué à -1.
[^] # Re: Incompatibilités ?
Posté par windu.2b . Évalué à 2.
J'ai dit que quand on a dans une page HTML (comme un squelette), un prologue XML sur la toute première ligne, et des balises PHP à certains endroits (pour afficher certaines infos: menus, zone principale, header & footer...) mais que les balises courtes sont tolérées, ben tu peux être sûr d'une chose: tu vas te faire jeter par l'interpréteur PHP!
Tout simplement parce qu'il a aura essayé de lire la toute première ligne de ta page (qui est le prologue) car il aura cru que c'était du PHP, mais n'aura pas su comprendre tout ce qui suit la balise...
[^] # Re: Incompatibilités ?
Posté par Gniarf . Évalué à 2.
là tu parles d'un fichier PHP, un squelette, qui donnera du XML en sortie du processeur PHP, enfin tu l'espères... mais tu considères que ce squelette est lui-même un fichier XML et doit donc forcément comporter ton prologue magique. à part des cas triviaux, c'est rarement vrai.
te faire jeter par l'interpréteur PHP est donc normal et surtout considérer que ton fichier d'entrée est (ou doit ou devrait être) un fichier XML même s'il est plein de balises et de code PHP (ou pire) est une aberration.
[^] # Re: Incompatibilités ?
Posté par François B. . Évalué à 1.
Spécification des processing instructions : http://www.w3.org/TR/2006/REC-xml-20060816/#sec-pi
[^] # Re: Incompatibilités ?
Posté par Gniarf . Évalué à 2.
oops, gcc il bouffe du C, pas du XML
c'est pareil avec PHP et ce setting préhistorique, il n'est pas fait pour manipuler du XML ainsi.
(et au passage, à l'origine PHP ne pouvait même pas interpréter du HTML, alors croire qu'il a été conçu pour travailler en bonne intelligence avec XML... bref. limite si c'est pas un accident s'il a choisi <? et pas [? ou autre (* ... tant mieux si ça permet des bidouilles, hein, c'est pas la question)
[^] # Re: Incompatibilités ?
Posté par tcheuck . Évalué à 1.
De la version 1 à la 5, le "moteur" de PHP à été réécrit deux ou trois fois quand même...
[^] # Re: Incompatibilités ?
Posté par François B. . Évalué à 1.
On n'a pas toujours la maitrise totale de ce qui se passe sur le serveur...
[^] # Re: Incompatibilités ?
Posté par Gniarf . Évalué à 3.
non. il est de bon ton que ce <?xml version="1.0"?> se retrouve au début de ta sortie de PHP, nuance. ça peut se faire autrement qu'en plaçant <?xml version="1.0"?> en début de script.
abruti d'admin chez ton hébergeur
problème isolé, plus qu'à agir \o/
[^] # Re: Incompatibilités ?
Posté par pw00t . Évalué à -3.
Rien que cet exemple d'avoir 2 balises pour marquer ton code, ca laisse pas augurer du meilleur..
Apres, php a l'air de vouloir se debarrasser de cette image de langage bourrin pour faire toutes les conneries de la planete, tant mieux :)
[^] # Re: Incompatibilités ?
Posté par tcheuck . Évalué à 1.
[^] # Re: Incompatibilités ?
Posté par Antoine . Évalué à 3.
Oui, parce que si on fait de l'objet c'est forcément propre et bien codé (tm).
La brigade idéologique des javalâtres a encore frappé.
[^] # Re: Incompatibilités ?
Posté par Camille_B . Évalué à 4.
La rétrocompatibilité est-elle si rare dans le monde des langages de programmation ?
Faut-il nécessairement que le langage passe par une phase de standardisation pour qu'il gagne une certaine stabilité lui permettant de traverser les âges sans demander au développeur de récrire son code tous les 4 ans ?
Si je lis les autres commentaires, apparemment la plupart des langages, sauf modifications majeures dans la conception même du langage (on citait python3000 mais je pense aussi au prochain perl), sont rétrocompatibles avec leur anciennes versions ...
[^] # Re: Incompatibilités ?
Posté par Julien Portalier . Évalué à 3.
Je n'ai pas suivi l'évolution de PERL, mais il me semble que c'est ce qu'ils ont choisi de faire pour la version 6 : repenser tout le language. D'ailleurs après avoir lu quelques trucs, il a l'air pas mal du tout ce PERL 6.
PHP intégre les changements graduellement. C'est pratique, car si on programme de manière propre, l'évolution du code est simple. Il suffit de lire les guides de migration, et on passe sans trop de difficultées d'une version à sa suivante. Mais c'est aussi un très gros inconvénient en ce que le language est inconstant.
D'autres languages, comme Ruby, ne devraient pas avoir ce problème à mon avis. Ils ont été conçus pour un style de programmation (pur objet), et ne mélangera pas plusieurs formes en un seul language (ce serait contraire à sa philosophie).
[^] # Re: Incompatibilités ?
Posté par Camille_B . Évalué à 7.
Finalement, pour en revenir à PHP, il s'agit d'une bonne chose Mais n'aurait-il pas été plus simple de 1) repartir de presque zéro et créer un PHP orienté objet à côté du PHP procédural ? ou 2) ne pas s'orienter vers l'OO et peaufiner le procédural ?
J'avoue ne pas avoir beaucoup d'atomes crochus avec l'OO. Comme je l'ai dit plus haut je ne suis pas un spécialiste en programmation. J'apprends la progra devant mon ordinateur avec LISP (sous plusieurs formes) et frôlant quelques autres langages. Autant le procédural ne me pose pas trop de problèmes et le fonctionnel m'excite au plus haut point, autant l'OO me semble apporter beaucoup de complexité pour un gain relativement faible. J'ai lu que l'OO facilitait la programmation en équipe et était plus adapté au jeu vidéo et au interfaces dites "graphiques".
N'ayant jamais programmé en équipe, ni créé de jeux vidéos, ni écrit d'applications pour un environnement de bureau quelconques, j'avoue ne pas pouvoir apprécier l'OO à sa juste valeur (un jour peut-être ...(j'ai d'ailleurs des doutes quand à la prétendu supériorité de l'orienté objet dans le monde des interfaces graphiques. Il est vrai que certaines excellentes fonctionnalités de NeXTStep/MacOSX/GNUstep ne seraient pas sans la capacité de l'Objective-C à gérer le typage et le chargement dynamique. Il est vrai que des environnements de bureaux, voire de simple gestionnaires de fenêtres, écrit dans des langages impératifs (je pense à Gnome et E17 écris majoritairement en C, si mes souvenirs sont bons) semblent plus "statiques" qu'un Kde ou un GNUStep. Pourtant ils fonctionnent, et plutôt bien. Mais je pense surtout à un gestionnaire comme Sawfish qui tire de LISP une très grande flexibilité, et la capacité à être modifié "dynamiquement" (désolé je n'ai pas les mots permettant de m'exprimer plus convenablement) grâce à l'interpréteur rep fournit.)).
Après cette longue introduction ma question est : l'Orienté Objet est-il vraiment indispensable à la programmation web côté serveur, ou s'agit-il ici de la conséquence de l'effet de mode entourant l'Orienté Objet dans le monde de l'entreprise ?
[^] # Re: Incompatibilités ?
Posté par Thomas Douillard . Évalué à 5.
Ce qui est particulièrement intéressant en objet c'est le côté : tu modélise tes données, tu as déja une partie de ton appli architecturée. Le modèle de données est écrit dans le code, c'est structuré : tu as les données et le code qui permet de les manipuler dans une seule classe. Tu me diras tu fais un package en procédural c'est la même chose. Mais quand tu codes avec un IDE, quand tu tapes le nom de ton objet, l'ide connait son type et te propose les méthodes que tu peux appeler c'est bien agréable. En bref ça facilite la vie du modélisateur/concepteur, du mec qui veut rentrer dans le code, des générateurs de code à partir de modèles, des codeurs d'ide, des codeurs tout court, etc. Tout ça parce que le code est plus "informatif" sémantiquement que du code procédural.
Et le fait que ce soit une appli web côté serveur n'influe pas beaucoup, ça dépend surtout de à quoi sert l'appli.
Le truc des interfaces graphiques c'est que l'objet colle parfaitement : un "bouton" <-> un objet. Un clic sur le bouton, ou sur un autre objet graphique <-> appel de la méthode dédiée. Mais ça veut pas dire que l'objet ne sert à rien sur des modèles moins "visuels" : une usine avec des employés, des machines, des salaires, des employés qui sont affectés à des machines, tu as facilement les classes de ton modèle.
Un truc pas mal aussi à mon avis : dans certaines API genre l'API java, la cohérence quand c'est bien conçu : n'importe quelle collection d'objet hérite de la classe collection, que tu manipule un vecteur d'objet, une liste d'objet, ou autre. Les méthodes sont les mêmes, les collections sont interchangeables.
Tu aimes bien le fonctionnel, un des points forts du fonctionnel selon moi c'est la généricité : fonctions d'ordre supérieur, etc.
En objet, tu as de la généricité aussi, de manière différente, plus évidente à capter question utilisation : l'héritage, l'implémentation de méthode virtuelle, par exemple. Entre autre.
[^] # Re: Incompatibilités ?
Posté par Camille_B . Évalué à 3.
Je vais jeter un ½il sur la modélisaition des données et les design patterns, domaine que je ne connais que de nom, raison pour laquelle je dois avoir manqué l'intérêt de l'OO.
En fait ma question était plus simple. Il est certain que l'orienté objet a beaucoup d'avantages, mais sa quasi omniprésence est-elle justifiée ?
J'ai l'impression, corrigez-moi si je me trompe, que l'OO est particulièrement populaire car il facilite la gestion de données complexes de plus en plus présente de nos jours via l'informatisation massive des infrastructures et la numérisation massive des données.
En réalité je n'ai pour l'instant jamais eu à traiter des données complexes dans le cadre de mon apprentissage strictement autodidacte de la programmation. Aussi l'OO m'apportait un surcroît de complexité qui me paraissait inutile.
Cependant je révise en partie mon jugement, je suis en train de m'initier à Ruby, et je dois avouer que pour une fois (après Objective-C, C#, et dans une moindre mesure Java) l'OO me paraît naturel !
En fait je crois que ce que j'aime par-dessus tout ce sont les langages sobres. Java ou C# sont bien trop verbeux à mon goût ;)
En tout cas merci pour toutes ces précisions qui viennent nourrir allégrement ma réflexion sur le sujet !
[^] # Re: Incompatibilités ?
Posté par Moonz . Évalué à 3.
Un article plutôt intéressant: http://www.etoile-project.org/etoile/blog/2007/07/road-to-co(...)
C'est quelque chose AMHA difficilement réalisable en procédural (et certainement pas élégamment)
[^] # Re: Incompatibilités ?
Posté par Camille_B . Évalué à 2.
Je suis régulièrement le développement d'Étoilé et de GNUStep. C'est d'ailleurs GNUStep qui m'a poussé à apprendre Objective-C. Langage définitivement trop obscure (je pense particulièrement aux implémentations de méthodes absolument hallucinantes) pour un débutant habitué à LISP. Et surtout, c'est un langage trop peu documenté.
L'apprentissage (ou plutôt le survol), m'a appris une chose : sans certaines de ses fonctionnalités (comme le chargement dynamique si je ne me trompe pas) une fonctionnalité comme le menu Services (bien connu également des utilisateurs de MacOSX) serait, sinon impossible, du moins très complexe à réaliser en C (par exemple).
Donc je suis tout à fait d'accord pour dire que l'OO apporte pleins de bonnes choses ;)
Mais ma question est toujours la même, son utilisation massive est-elle toujours justifiée ?
[^] # Re: Incompatibilités ?
Posté par CrEv (site web personnel) . Évalué à 1.
C'est pas si "n'importe quoi" que ça... (attention, je suis pas forcément pour non plus...)
Il n'y a pas si longtemps (bon en fait si) on avait des fichiers .php3 et des .php4 qui étaient souvent des .php
Donc oui, dans ce cadre de transitions et surtout de mélange de php sur un même serveur je trouve ça normal et pratique d'avoir des extensions différentes (mais pour moi .php doit toujours rester la version courante, et .php#{oldversion} pour les autres)
(troll) ps : saurez-vous reconnaitre le langage que j'utilise actuellement ? ;-)
[^] # Re: Incompatibilités ?
Posté par tcheuck . Évalué à 1.
C'est les hébergeurs qui ont lancé cette mode. Utiliser des .htaccess est beaucoup plus propre.
[^] # Re: Incompatibilités ?
Posté par defdrek . Évalué à 2.
Vu les problèmes causés par la transition "forcée" de VB6 vers VB.NET, je pense que ça serait donner la bâton pour se faire battre :)
[^] # Re: Incompatibilités ?
Posté par Camille_B . Évalué à 1.
La vérité c'est que Microsoft en conseillant de passer à VB.NET a tout simplement mit fin au langage Visual Basic "standard".
Comme VB6 et VB.NET sont tous les deux des produits Microsoft, il était plus facile de faire croire à une mise à jour du langage.
[^] # Re: Incompatibilités ?
Posté par defdrek . Évalué à 2.
[^] # Re: Incompatibilités ?
Posté par astero . Évalué à -1.
Bizarre, j'ai pourtant l'impression d'utiliser un paquet de fonctions quand je code PHP.
Rien à voir avec du Java ou du C# en tout cas... qui eux sont des langages objets je pense.
[^] # Re: Incompatibilités ?
Posté par tcheuck . Évalué à 0.
C'est ce qu'on appelle la rétrocompatibilitée...
[^] # Re: Incompatibilités ?
Posté par astero . Évalué à 6.
Tu m'expliques alors comment on fait pour avoir la longueur d'une chaine sans passer par une fonction ?
str_length($foo) aurait pu être qualifié de rétro compatibilitée si il ya avait un $foo.length() mais il n'y en a pas. Pareil pour les tableaux et tous les types de bases.
Désolé mais quand même les string et les tableaux ne sont pas de objets, bah on code pas objet...
Comment tu manipules les fichiers ? avec des objets ? nan... bref, en PHP pratiquement rien n'est objet, s'il y avait les équivalent alors OUI on pourrait parler de rétro compatibilité
Au passage cite moi des libs STANDARDS qui sont orientées objets... alors il y a déjà PDO et euh... euh...
[^] # Re: Incompatibilités ?
Posté par Julien . Évalué à 4.
Sans vouloir troller, je pense que PHP occupera de moins en moins de part de marché dans le futur, quand on voit tout les problèmes et les incohérences de ce "langage" ...
[^] # Re: Incompatibilités ?
Posté par tcheuck . Évalué à 5.
Tu te trompe, pour deux raisons:
- C'est un langage très facile à apprendre, avec une communauté énorme,
- Pour celui qui ne sait pas programmer, il y'a une quantité industrielle de CMS en tous genre, et c'est souvent l'envie de modifier ceux-ci pour l'adapter a son site qui fait que l'utilisateur moyen se lance dans l'apprentissage de PHP.
[^] # Re: Incompatibilités ?
Posté par Anonyme . Évalué à 5.
Et tout ca fait beaucoup de mal a l'informatique ... parce que ces gens apprennent mal, et propagent leur mauvais savoir faire au sein de leur communauté. Ca me fait penser a l'actionscript (jusqu'au 2 au moins), ou des graphistes en viennent a dire que la programmation c'est de la merde, parce que le moindre truc leur demande des heures de boulot, ils en arrivent a faire une mosaique de code variant entre mauvais et catastrophique pioché ici ou la sur le net, sans se rendre compte que cette techno est un truc immonde, ou même un dévelopeur aguerri peut avoir beaucoup de mal a faire du code propre.
Quoiqu'il en soit tu as raison : ces deux points son la garantie que l'on est pas pret de voir php disparaitre mais j'espère que php ne fera pas autant de mal a la programmation de serveur web que le COBOL a fait a l'informatique d'entreprise.
[^] # Re: Incompatibilités ?
Posté par Stéphane Traumat (site web personnel) . Évalué à 0.
http://about.me/straumat
[^] # Re: Incompatibilités ?
Posté par CrEv (site web personnel) . Évalué à 6.
[^] # Re: Incompatibilités ?
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
C'est comme de dire que de plus en plus de gens vont connaître le C car beaucoup se mettent à Linux. Non, ils se contentent d'utiliser linux comme les gens se contentent de plus en plus d'utiliser un CMS
Pour ce qui est de la communauté, c'est vrai que PHP a su crée une communauté énorme grâce à ses qualités. Maintenant, il y a vraiment de tout dans cette communauté....
http://about.me/straumat
[^] # Re: Incompatibilités ?
Posté par Julien Portalier . Évalué à 5.
Je code en PHP depuis longtemps, en PHP 5 depuis au moins deux ans. J'ai même codé un framework MVC l'an dernier pour me faciliter la tâche (n'aimant pas ceux existants) et apprendre la forme objet de PHP 5.
Curieux, j'ai jeté plusieurs fois un ½il à Ruby. Je ne l'ai pas aimé les premiers temps, car la forme me rebutait. Cependant ces dernières semaines, j'ai lu les livres Why's (Poignant) Guide to Ruby et Programming Ruby (The Pragmatic Programmer's Guide)[2]. J'ai alors pris conscience de la vétusté (et de la staticité) de PHP ! Ruby est un language élégamment pensé, dans sa conception comme dans sa syntaxe et ses possibilités.
Je n'ai pas encore lu les livres sur Ruby on Rails que je saisi déjà toute sa puissance, et pourquoi Rails ne peut pas exister dans un autre language (moi aussi j'étais sceptique... avant). Je sais déjà que lorsque je serai au point sur Ruby, je passerai à Rails ; et lorsque je serai au point sur Rails, je laisserai tomber PHP, sans regrets (juste de la nostalgie). Ce qui me retient d'y passer de suite c'est que je suis efficace en PHP et qu'il va me falloir encore un peu de temps pour vraiment l'être en Ruby. Quoiqu'en fait il me faut juste lire un bouquin sur Rails, et me lancer.
Le seul truc qui m'embête c'est que la doc librement accessible de Ruby on Rails est assez spartiate -- seule la réf. est vraiment complète, ce qui est un peu abrupt pour découvrir le framework. Il faut donc acheter les livres. C'est dommage. En attendant les livres pour Ruby sont librement accessibles, notamment sur http://ruby-lang.org/fr/
[1] http://qa.poignantguide.net/
[2] http://www.rubycentral.com/pickaxe/
> C'est un langage très facile à apprendre
Ruby n'est pas dur. Vraiment. Sa syntaxe est pensée pour arranger le développeur, pas l'interprêteur (qui finalement y trouve très bien son compte). Cependant pour bien saisir Ruby, il vaut mieux avoir une bonne connaissance de la programmation et une connaissance solide de l'objet au préalable. J'avais déjà été impressionné par le modèle objet de PHP 5. Celui de Ruby est incomparable.
> Pour celui qui ne sait pas programmer, il y'a une quantité industrielle de CMS en tous genre, et c'est souvent l'envie de modifier ceux-ci pour l'adapter a son site qui fait que l'utilisateur moyen se lance dans l'apprentissage de PHP.
C'est justement là le problème de PHP. Des tas de CMS et de frameworks dans tous les coins. Tellement de diversité qu'on ne sait plus vers quoi se diriger. Du coup on finit par coder ses propres outils, ce qui ne règle rien au problème.
[^] # Re: Incompatibilités ?
Posté par Nicolas Blanco (site web personnel) . Évalué à 2.
pour ma part ça a été l'inverse. J'ai découvert Rails directement après quelques années de PHP sans passer par Ruby. Et ça a été le paradis. ça l'est encore aujourd'hui.
Effectivement pour s'y mettre il faut acheter un bouquin. Mais quel bouquin (je parle de Agile Web Development with Rails/Ruby on Rails chez Eyrolles en VF) ! J'ai rarement lu un bouquin aussi bien écrit, on sent la passion derrière. Plus que vouloir transmettre des connaissances, ce bouquin donne aussi envie d'utiliser ce framework, de s'y attacher. C'est limite de l'endoctrinement :).
Pour moi le meilleur bouquin de développement Web de ces 2 dernières années.
Je pense qu'avec un minimum de bagage en programmation objet, on a pas besoin de commencer à apprendre Ruby pour se mettre à Rails. J'ai commencé avec Rails et progressivement j'ai appris Ruby sans problème.
Comme dit, ce que j'adore avec Rails c'est la communauté de trolleurs passionnés autour. Contrairement à d'autres langages avec des centaines de bibliothèques, frameworks, etc, on avec Rails un ensemble homogène de qualité et une énorme communauté derrière.
Si vous ne connaissez pas, testez :).
Nicolas.
[^] # Re: Incompatibilités ?
Posté par BAud (site web personnel) . Évalué à 3.
http://fr.poignantguide.net/
la version draft est là : http://fr-draft.poignantguide.net/ sous licence CC-by-sa
[^] # Modèle objet de Ruby
Posté par Arthur Accroc . Évalué à 0.
Je ne dirai rien, je ne le connais pas (encore; si je retrouve mon hors série PHP 5 de Linux Mag, j'y jette un coup d'oeil cet été).
J'avais pensé ça aussi, quand j'avais essayé Ruby, et puis j'ai eu besoin d'un destructeur.
Je sais, s'il n'y a pas de destructeur, c'est dû au choix du garbage collector (alors peut-être est-ce un mauvais choix) et il y a moyen de contourner (mais c'est plus lourd et j'aime les langages qui supportent ma façon de penser et non pas qui m'imposent la leur).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Modèle objet de Ruby
Posté par Camille_B . Évalué à 5.
Le langage compatible avec ta façon pensée impose tout autant sa façon de pensée, mais comme elle colle avec la tienne tu ne t'en rend tout simplement pas compte.
[^] # Non
Posté par Arthur Accroc . Évalué à -1.
Mettons que je t'accorde qu'un langage fait forcément des choix pour ses grandes orientations : principalement impératif ou purement fonctionnel (sans parler d'autres principes comme le moteur d'inférences de Prolog), à typage statique ou dynamique, verbeux ou concis,etc..
Au delà, je ne suis pas d'accord avec toi, parce qu'il y a au moins un contre exemple à tous les langages qui imposent la façon de penser de leur(s) auteur(s). Larry Wall a conçu Perl avec comme devise "There Is More Than One Way To Do It". Et comparé aux langages qui partagent les mêmes orientations principales, comme Ruby ou Python, il n'y a pas photo.
Si je veux utiliser des destructeurs, j'en ai. Si je préférais utiliser des fermetures à tout va comme l'absence de destructeurs l'impose en Ruby, je pourrais, ça marche, je l'ai fait une fois (une seule) où ça me semblait réellement approprié.
Si je veux une vérification rigoureuse que j'ai bien initialisé toutes les variables que j'utilise, c'est possible. Si je préfère qu'il m'initialise tout seul les variables auxquelles je fais référence, c'est possible aussi.
Je peux programmer en orienté objet (au moins, je dispoise du paradigme object complet, avec les destructeurs (pourvu que ça résiste au GC de la version 6)), mais si je préférais me cantonner à un style impératif, je pourrais aussi...
Alors je reprendrai ta phrase en disant que la plupart des langages imposent leur façon de penser. À part certains dont l'intérêt est justement une façon de penser profondément originale et particulièrement appropriée à certains types de problèmes, ce sont en général les langages que je n'aime pas.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Non
Posté par Antoine . Évalué à 2.
C'est vrai qu'il n'y a pas photo : Perl est une merde sans nom.
[^] # Re: Non
Posté par Arthur Accroc . Évalué à 1.
Pour moi, c'est un avantage : je me vois déjà bien trop souvent obligé de travailler avec des buses (j'ai même un collègue dont le boulot consiste en bonne partie à faire du PHP, à qui j'ai dû expliquer comment faire un truc en PHP, alors que je ne connais pas le PHP), donc toute occasion de l'éviter est bonne à prendre.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Incompatibilités ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Moi ça fait des années que j'entends ça, et pourtant....
[^] # Re: Incompatibilités ?
Posté par astero . Évalué à 2.
Après faut quand même avouer que pour un dev qui ne soucie pas de ça (appli interne par exemple), php a de moins en moins d'arguments... surtout quand on regarde ce qui se fait à coté (ruby, python, .net pour ne citer qu'eux)
[^] # Re: Incompatibilités ?
Posté par Gniarf . Évalué à 2.
[^] # Re: Incompatibilités ?
Posté par astero . Évalué à 2.
Peut être 1% des intéressés et encore !!
Mais c'est vrai que niveau perfs j'ai cru lire que les challengers (ruby et python par exemple) avaient quelques détails à revoir... mais c'est un autre troll :)
[^] # Re: Incompatibilités ?
Posté par vieuxshell (site web personnel) . Évalué à 1.
Ben en fait tout ceux qui utilisent un langage pour développer une application (bien faire la différence entre écrire une applie et faire un script web).
[^] # Re: Incompatibilités ?
Posté par BAud (site web personnel) . Évalué à 3.
les hébergeurs aussi peut-être justement ? :D (en plus des mécanismes de sécurité disponibles).
cf. http://faq.tuxfamily.org/WebArea/Fr#Pourquoi_TuxFamily_ne_fo(...)
php a beau être un trou de sécurité béant, il a les mécanismes autour (suphp, safe_mode) qui permettent de le déployer en protégeant a minima les données des autres utilisateurs, du système... ce que n'ont pas (encore ?) les autres.
Puis bon côté conso RAM/CPU, python, ruby et consors n'ont qu'à faire leurs preuves, c'est particulièrement important sur un hébergement mutualisé (balancez les benchmarks si vous avez).
[^] # Re: Incompatibilités ?
Posté par Antoine . Évalué à 3.
http://shootout.alioth.debian.org/
[^] # Re: Incompatibilités ?
Posté par Antoine . Évalué à -1.
Ils sont rigolos les guignols de chez TuxFamily. Je cite :
"Pour PHP, en cas de gros soucis de charge, on peut utiliser eaccelerator, avec perl et python on est coincés."
Alors qu'eaccelerator n'est un cache de bytecode, qui existe en standard avec Python (fichiers .pyc).
[^] # Re: Incompatibilités ?
Posté par Sylvain Rochet (site web personnel) . Évalué à 3.
"Pour PHP, en cas de gros soucis de charge, on peut utiliser eaccelerator, avec perl et python on est coincés."
Alors qu'eaccelerator n'est un cache de bytecode, qui existe en standard avec Python (fichiers .pyc)
C'est toujours agréable ces gentils mots... mais bon passons
Bon alors en finalité, php est si rapide à compiler son code que les performances sont plutôt moins bonne (en tous cas ça ne change presque rien) si on va lire le bytecode en cache disque (même sur des disques SCSI à 10K). Ce n'est pas vrai si le bytecode est stocké en mémoire en shared memory, mais pour cela en mutualisé il faut plusieurs giga de mémoire sur chaque serveur web, ou alors distribuer les sites sur les noeuds, mais ce n'est pas dans la philosophie de TuxFamily de brider un site sur un seul serveur web (service équivalent pour tout le monde, n'importe quand).
[^] # Re: Incompatibilités ?
Posté par Antoine . Évalué à -1.
Ca ne change rien : soit le cache de bytecode sert à quelque chose et Python fait aussi bien en standard que PHP+eaccelerator, soit il ne sert à rien et ce n'est pas la peine de prétendre qu'eaccelerator rend PHP plus rapide.
Dans les deux cas l'affirmation du wiki tuxfamily est totalement erronée.
Pour ce qui est de la RAM elle coûte de moins en moins cher, aucune raison de s'en priver, d'autant que vu le working set d'un hébergement mutualisé il vaut mieux en avoir de la RAM...
ou alors distribuer les sites sur les noeuds
Il me semble que c'est ce que fait n'importe quel hébergeur qui pense un peu à se prémunir de la croissance du nombre d'utilisateurs. La solution de tout mettre sur un gros disque réseau partagé (type NFS) me semble totalement injustifiée vu les dégradations probables en performances et robustesse.
[^] # Re: Incompatibilités ?
Posté par Sylvain Rochet (site web personnel) . Évalué à 5.
C'est juste qu'il n'est pas a jour... d'ailleurs c'est un wiki tu peux te loguer puis le modifier et contribuer utilement !
Pour ce qui est de la RAM elle coûte de moins en moins cher, aucune raison de s'en priver, d'autant que vu le working set d'un hébergement mutualisé il vaut mieux en avoir de la RAM...
Il me semble que c'est ce que fait n'importe quel hébergeur qui pense un peu à se prémunir de la croissance du nombre d'utilisateurs. La solution de tout mettre sur un gros disque réseau partagé (type NFS) me semble totalement injustifiée vu les dégradations probables en performances et robustesse.
Si le stockage n'est pas centralisé, cela complique la gestion. Deja l'architecture décentralisé est plus complexe, il faut donc plus de gens pour la gérer (et oui). Ensuite, il faut plus de matériel, car cela sous entend d'avoir du stockage sur chaque serveur web, et de le dupliquer (et j'imagine même pas comment gérer simplement le basculement d'une panne d'un serveur web sur un autre en cas de problème, les solutions libres ne sont vraiment pas encore au point, et TuxFamily n'utilise que du libre, par principe). Un problème final s'ajoute à cela, le cout, si tu as 10K Euros à nous donner pour qu'on mette cela en place, on les prend sans problème et on le met en place ! Et pour finir, actuellement on a très peu d'accès disque, on a déplacé la grosse consommation d'accès disque (aka les gros fichiers statiques, iso, ...) sur une 2ème architecture et on a énormement de cache sur le serveur NFS (et oui, payer plusieurs GB de mémoire une fois on peut se le permettre, 10x on peut pas).
Ah oui aussi, même si le service web est le plus consommateur, ca fait juste parti d'un des services qu'on fournit, ca complique légérement la décentralisation (sans oublier la gestion des quotas) :-)
Et pour la croissance on gère, aujourd'hui ça va, demain, on verra !, le problème n'est pas technique, il est de temps et d'argent ! :)
# Quand ça marche, pourquoi changer ?
Posté par Grumbl . Évalué à 5.
Une chose est certaine : je ne les ré-écrirai pas en PHP5 pour rien. Et je doute qu'on me le demande : la valeur ajoutée de la chose serait nulle pour le client.
[^] # Re: Quand ça marche, pourquoi changer ?
Posté par Victor STINNER (site web personnel) . Évalué à 1.
Et les patchs de sécurité ? PHP4 finira pas ne plus du tout être mis à jour.
Je pense que la màj PHP4 => PHP5 fait chier tout le monde car tout le monde code comme un porc avec PHP4 et que ça marche plus avec PHP5 qui est un légèrement (*) plus strict.
En tout cas : http://maurus.net/work/php-sucks/
(*) On peut toujours écrire « $foo=null; echo $foo->bar[0]->foo["bar"]; » en PHP5. Ouf, on peut encore gruiiiiker comme des sagouins.
[^] # Re: Quand ça marche, pourquoi changer ?
Posté par astero . Évalué à 1.
Hmm... ça serait vraiment pas sympa de leur part ça !! en tout cas ils précisent bien que ce sera fait pour l'instant.
Et je suis d'accord avec le premier post, la valeur ajoutée est strictement nulle dans 99% des cas, alors pourquoi investir dans une mise à niveaux ? sachant qu'un dev coute quand même relativement cher !!
[^] # Re: Quand ça marche, pourquoi changer ?
Posté par PierreJ . Évalué à 1.
"Une chose est certaine : je ne les ré-écrirai pas en PHP5 pour rien. Et je doute qu'on me le demande : la valeur ajoutée de la chose serait nulle pour le client."
je me demande quelle ta valeur ajoute pour le client concernant PHP. Si tu prends 2.5 min pour lire les guides de migrations, tu te rendras compte qu'il n'est absolument pas necessaire de reecrire une applie... Dans le pire des cas, tu te retrouves avec un warning ou une notice.
[^] # Re: Quand ça marche, pourquoi changer ?
Posté par keke . Évalué à 0.
[^] # Re: Quand ça marche, pourquoi changer ?
Posté par zlnix . Évalué à 1.
J’aime ce langage pour faire de petites choses, je voterais même pour qu’il soit utilisé plus souvent pour de l’administration système, petit automates etc... mais à faire de trop gros projets non !
Car l’implication suivante devrait être respectée
si gros projet -> grosse conception
Et encore une fois, force est de constater que le codeur PHP n’est pas un adepte de ces méthodes.
Ou plutôt l’on nous a fait croire que nous n'en avions plus (ou pas) besoin (re hmmmf) . Donc à mon humble avis, au lieu de pleurer sur ce que fait ( ou pas ) un langage il faudrait voir déjà ce que peut déjà faire le codeur ... c’est les codeurs qu’il faudrait migrer en mode projet :-)
[^] # Re: Quand ça marche, pourquoi changer ?
Posté par tcheuck . Évalué à 1.
Ca serait pas plutôt l'inverse ?
[^] # Re: Quand ça marche, pourquoi changer ?
Posté par Guillaume Rossignol . Évalué à 2.
.
Fondamentalement c'est la majorité des codeurs PHP qui ne savent pas écrire un projet et ils faudrait les passer en version projet (les codeurs)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.