Hello tlm,

je sais que ce thread ne va pas rester très longtemps, vu que ça défile pas mal quand même, donc si vous êtes intéressé par la discussion, dépêchez-vous ;-)

J'ai décidé d'écrire quelques lignes pour donner ici des nouvelles de PHP. Je sais que les "pro" suivent sans aucun doute l'actualité de ce langage, mais bon...en discuter ici peut-être sympa, et ça peut intéresser les moins "pro", qui, eux, ne suive pas forcément son évolution.

On commence par l'Annonce, avec un grand A, quand même : PHP4 est mort. C'est fini. Il n'y aura plus de nouvelle version de PHP4, l'équipe de développement de PHP ne suivra plus ce projet.
D'aucun prédise du coup que les hébergeurs vont l'abandonner rapidement. Pas si rapidement, à mon sens, quand même...ça ferait du grabuge. Mais ça va venir quand même : le web évolue sans cesse, et un langage qui n'évolue pas avec est voué à une mort certaine et douloureuse. Ils se plieront donc aux nouvelles exigences technologiques pour apporter à leurs chers clients ce qui se fait de mieux :-)

PHP6 est prévu pour 2008. C'est à dire qu'il y a quelques mois entre la mort de PHP4, et la naissance de PHP6.  Et alors, me direz-vous. Et alors ? Cela fait 3 ans que PHP5 existe. Pourtant, si on regarde les offres d'hébergement, on a l'impression que PHP5 vient tout juste de sortir : la plupart offre une double architecture, et beaucoup en sont restés uniquement à PHP4. En 3 ans...Et là, avec PHP4 qui se meurt et PHP6 qui tarde à arriver, ben ils vont passer probablement en grande majorité à PHP5. Mais s'ils font ça, ce n'est certainement pas pour changer à nouveau quelques mois plus tard, pour PHP6.
Donc, une crainte de beaucoup c'est qu'encore une fois, l'offre des hébergeurs prenne un sacré retard sur les évolutions de PHP, et que l'on garde majoritairement PHP5 même des années après la sortie de PHP6. La vie est un éternel recommencement...Ca, ça ne me fait pas plaisir : pour les pro (je veux dire les vrais pro, les professionnels du PHP, ce qui gagnent leur vie avec -comme moi, quoi- ce n'est pas horrible : ils travaillent généralement sur des serveurs dédiés, et y installeront bien vite PHP6. Mais la plupart des amateurs éclairés, eux, ne pourront jouer avec PHP6 qu'en local, chez eux, et devront se coltiner un PHP5 qui sera de plus en plus vieillissant, pour les sites qu'ils partagent avec la communauté.
Triste.

PHP6, au fait...quoi de neuf ? Bon, je reviens rapidement sur ce que l'on sait de longue date :
support unicode, enfin!
A mort magic_quotes, enfin!!
Bye Bye register_globals! Ouf!
safe_mode, on ne t'aimait guère...on ne te regrettera point!
Et j'en passe : des supports qui ne seront plus supportés, une gestion plus stricte des erreurs etc etc.
Et dernièrement : les namespace! Et oui, c'est officiel, PHP6 va implémenter les namespace.
Pour ceux qui ne savent pas, un namespace (espace de nom) permet, en gros, de préfixer des fonctions, variables, classes etc...qui sont dans cet espace de nom. Lorsqu'on fait un appel dans un espace de nom, PHP ira d'abord chercher dans cet espace de nom, et s'il ne trouve pas, remontera vers l'espace de nom global (je n'ai pas trouvé une meilleure expression, là, désolé).
Pour ceux que cela intéresse, suivez le lien vers le cvs de PHP qui explique la nomenclature choisie:
http://cvs.php.net/viewvc.cgi/php-src/README.namespaces?revision=1.6&view=markup&sortby=date

Moi, je trouve tout ça très intéressant :-) Même si on se raproche de plus en plus d'un style Java. Il serait peut-être sympa d'innover un peu plus...mais bon.

Salut
magic_quotes moi j'etais pour son maintiens...

namespace, c'est probablement utile :) on fait sans, avec des classes qui contiennent uniquement des static...

si on regarde l'OO de php5, que manque t'il ?
1) une surcharge genre __toInt, __toFloat, __fois($var), __plus($var) ...
2) une gestion de l'heritage multiple
3) autoriser a implementer de facon abstraite une fonction interfacee :
interface A{
 public function truc();
}
abstract class B implements A{
 abstract public function truc();
}

actuellement, on est oblige de mettre
abstract class B implements A{
 public function truc(){}
}

c'est laid...

si on regarde les stream :) c'est cool, mais :
imagejpeg('747://GetStr/image'); ne fonctionne pas, les libs utilisent leurs propres fopen, et non le fopen du php :(

---

une recherche sur exalead vous aurait peut-etre evite de poser cette question

Hello Coucou,

bah moi magic_quotes je n'ai jamais aimé : ça ne prévient pas grand chose. Au mieux, ça fait croire aux codeurs que les données uitilisateurs sont "safe" parce que PHP gère tout, ce qui est totalement faux. Ca ne protège qu'en partie. De plus, ça va pour une insertion de saisies utilisateurs dans une base mysql (sans tenir compte des injections et autre XSS), mais c'est juste du bol : mysql est une des rares BDD à utiliser l'antislash pour échapper des caractères. Moi je bosse avec mssql, alors bon...

Je serais ausis assez content d'avoir une façon built-in de gérer du multi héritage : ça alourdit les développements quand on en a besoin, de passer par des techniques de programmation diverses et variées afin de l'implémenter (bon, encore, ça va : c'est possible!). mais apparemment, ça n'est pas à 'ordre du jour. D'un côté je comprends : c'est vite le bordel, le multi-héritage...si on n'est pas très très minutieux. Mais bon...j'aimerais quand même en avoir la possibilité.

Pour les surcharges "magiques", ouais, pourquoi pas. Même si je vois mal ce que ça ajouterait : __toString est appelé en faisant un echo sur l'objet même. IL faudrait alors trouver un moyen de flagger l'objet pour lui indiquer quelle méthode utiliser lorsqu'on l'"echo". Je parle là des __toInt ou __toFloat. Mulitplier, ajouter, ce serait pas mal, par contre, un pendant à __clone() qui pourrait être utile, ouais :-)

Pour les interfaces et abstractions, personnellement dans un tel cas je n'implémente pas la méthode dans la classe abstraite :

interface A {
    public function foo();
}

abstract class B implements A {
    public function bar() {
       //bar process
    }
}

class C extends B {
    public function foo() {
       // foo process
    }
}

Pour les stream, je pense qu'il faut passer par les stream, justement ;-) Mais oui, ce serait bien d'unifier un peu tout ça : je trouve que c'est bordélique et complexe, de toute manière.

Ce que j'aurais aimé, moi, c'est la possibilité de partager une même propriété plus  facilement, entre une classe parente et ses classes enfants. Un genre de super($propriété). Une propriété statique cross-objets, quoi.

Salut

ton code lance un message d'erreur

les stream ca marche tres bien pour beaucoup de fonctions, mais ni fsockopen, ni imagejpeg

---

une recherche sur exalead vous aurait peut-etre evite de poser cette question

Pas sur ma version PHP 5.2.3, et pas depuis 5.2 à priori

Salut

PHP Version 5.2.1

arg... on va oublier ce passage... j'etais pourtant sur que... mais en refaisant des tests... bah non :) donc j'ai plein de :

function a(){ throw new exception747('cannot call this function');}

a supprimer, avec la doc qui va avec :)

---

une recherche sur exalead vous aurait peut-etre evite de poser cette question

Lol ouais en effet. C'est plus élégant de ne pas la redéclarer dans la classe abstraite, et moins lourd ;-)
Bah j'ai découvert ça il y a peu, en fait. Je ne m'étais jamais posé la question parce qu'il me semblait évident que c'était impossible.
mais non :-)

Hello,
Pour ce qui est de magic quotes, même s'ils sont off par défaut, je pense que tous les hébergeurs les remettront à on, sinon ça poserait trop de problèmes de sécurité pour les sites existants.
Ce qui est marquant pour moi, c'est le passage à unicode, parce que les mb_detect et autres encode/decode avec les PCRE en particulier, c'était un peu fatigant ! Vivement que le utf8 s'impose dans l'esprit de tous comme la norme. Un article très complet que j'ai trouvé là-dessus : [ Lien ]. Chapeau pour le boulot réalisé 8D
Après les nouveautés de POO, pour moi et tous ceux qui l'utilisent à petite dose ou pas du tout, on ne verra pas tout de suite la différence ! Les namespace, pourquoi pas, mais çe n'encouragerait pas au laxisme dans les notations ça ? Et pour l'effort que ça demande de rajouter soi-même des préfixes, ça me paraît plus clair à la relecture.. mais bon j'ai jamais testé :p

@Evangun

Ouais, je suis d'accord, le support unicode est LE changement majeur de PHP6. Ca va franchement nous faciliter la vie! Maintenant, je pense que ça va générer pas mal d'incompréhension, et prendre beaucoup de temps avant d'être utilisé correctement.
Pour les magic_quotes, de toute manière, il est évident qu'ils vont continuer à être utilisé longtemps. Ils sont déjà à Off par défaut depuis PHP5. Avec PHP6, ils disparaitront. Mais ça laisse bcp de temps...en effet.

Pour les namespaces, évidemment, ce ne sera pas utilisé par beaucoup de développeurs. En tous cas, par très peu d'amateurs (la grosse majorité de la communauté PHP). Mais en tant que professionnel, je trouve que c'est très intéressant.
Tien, un exemple parlant qui pourrait intéresser tout le monde (entre autres utilités des namespaces hein) : tu utilises des classes externes, codées par d'autres, plusieurs, dan sun projet à toi, avec tes propres classes aussi. Ca, c'est fréquent, bcp le font. Mais si jamais tu as deux classes ayant le même nom ? Qui sont chacune accompagnée de tout un framework, avec des incompatibilités entre les deux ? Un exemple qui me vient à l'esprit, c'est pour javascript, mais bon...lol...j'ai pas d'exemple en php là : prototype et JQuery par exemple. Tu ne peux pas utiliser les deux en même temps facilement, SAUF en utilisant le concept de namespace: JQuery.$('.class') me semble t il.)
Les namespaces en PHP permettront de répondre à ça :
<?php
namescape A;
class generic {
    public function foo();
}
?>
<?php
namespace B;
class generic {
    public function bar();
}
?>
<?php
require_once 'A.php';
require_once 'B.php';
importt A::generic;
importe B::generic;
$A = new A::generic;
$B = new B::generic
$A->foo();
$B->bar();
?>

Bon c'est juste un exemple et je ne suis pas encore très sûr de comment ils vont fonctionner. Apparemment, y a pas mal de choses sympas qui se profilent à l'horizon, concernant les namespaces. On verra :-)

Oui, bien vu le cas des scripts préexistants et incompatibles, on n'a plus à les modifier directement ! Ok c'est bon t'as gagné, je suis fan :D :D :D

Ha mais avec php6 il n'y aura plus du tout la possibilité de mettre magic quotes à on ! je n'avais pas compris ça... houlà mais c'est grave lol.

Du coup quelle est la bonne pratique ? Perso, j'ai toujours bien aimé le fait d'échapper tout le tableau POST et de ne plus s'en occuper par la suite.

Pour faire un script compatible php 5 et 6, est-ce qu'on peut écrire

if(get_magic_quotes_gpc() === 0)
{
     $_POST['truc'] = addslashes($_POST['truc']);
}

ou est-ce que get_magic_quotes_gpc() renverra une erreur sous php6 ?

Au passage, je vois que la version 5.2.4 de php est sortie avant-hier.