On vient de lever la polémique au taff et du coup je me suis dit que de poster mon avis sur la question… En effet, j’entends souvent “mais PHP y’a pas de spécification alors que Java/J2EE au moins tu code correctement”. Ce genre de remarque n’est pas forcément sujette au trolling, car elle a tout son sens dans des travaux d’entreprise. Alors voilà, je pense qu’il faut réellement poser les faits et se poser des questions sur ce genre de remarque.

Java est un langage objet structuré en couches, J2EE est un ensemble l’api et de spécifications. Donc comparer PHP et J2EE n’a pas de sens. Dans ce cas précis, il faudrait comparer une API spécifique PHP, ou un Framework comme (et oui vous n’y couperez pas) Copix, Zend, Symphony… Tout de suite la donne change. Ces frameworks **imposent** justement une sémantique et une structure de code que vous ne pouvez pas (ou presque pas) contourner. Les règles de nommage et même de typage (et si…) sont bel et bien là.

Coder comme un goret en Java: je peux, et même en J2EE… amusez-vous à poser des JSP bien lourdes et mal faites, vous allez voir si votre structure est maintenable :) Mais sans plaisanter, je ne comprends pas ce jugement //anti-PHP// qui amène en avant plan une spécification propre: le typage. Suivez moi…

D’abord, pour couper court à la remarque “on peu envoyer n’importe quoi dans les fonctions”, rien ne vous empêche de forcer un type à entrer dans une méthode… par exemple: class Foo { public function getUserId(User $u){ return (int)$u->id; } }

Si la variable $u n’est pas de type “User” alors une erreur apparait ! Sinon, vous pouvez jouer avec les Exception en testant le type de la variable récupéré via “instance”.

Ensuite, le type scalaire de PHP permet justement un transtypage aisé que ne permet absolument pas Java. Oui, on peut ne rien déclarer et utiliser des variables n’importe comment mais c’est là qu’entre en jeu le framework ou les API !!! tout comme le fais J2EE !

Un point qu’il ne faut pas oublier messieurs dames, c’est que Java/J2EE demande une infrastructure statique et dynamique, car bien que les JSP soient dynamiquement compilées, il n’en est pas de même pour les classes définis dans l’architecture… Chose que PHP se garde bien de faire, effectivement en PHP tout est dynamique…

Ce que je reproche donc à la critique PHP vs J2EE c’est qu’elle n’a pas lieu d’être, il faut avant toutes choses comparer ce qui est comparable. Si par contre nous voulons comparer Java et PHP alors je suis prêt à écouter toute remarque sur le coté “crade” de PHP que je peux aisément reproduire en JAVA.

Notez enfin que je n’ai rien contre Java, je l’utilise souvent (j’ai un projet sur Red5 en ce moment) et je vois parfaitement où PHP aurait été tellement plus appréciable. Java empêche beaucoup trop de code logique, jusque là je n’ai jamais put faire “mieux” en Java qu’en PHP. J’entends par “mieux” un code plus léger et moins complexe à réaliser pour le même résultat.

Un exemple avec PHP/Copix que je ne sais pas faire aisément en JAVA/J2EE: ` /** -Classe qui retourne un objet instancié: factory pattern

class InstanciateFactory {

/**

-Retourne un objet selon le nom donné en argument si celui-ci existe -dans la table ‘classes’. Sinon, lève une exception -@param string $objname -@return object

public function create($objname=null){
    if (!is_string($objname)) throw new Exception('Object has to be string');
    //utilisation de l'api copix pour l'exemple:
    if($result = _dao('classes')->findBy(_daoSP()
        ->addCondition('classname','=',$objname)
    )){
        return new ${$result[0]};
    }

    throw new Exception($objname.' class not found in database');
    
}

} `

Je vois pas trop comment faire plus simple et aussi fonctionnel en Java… J’ai plein d’exemple dans ce cas… mais à l’inverse, je n’en trouve pas en Java que je ne puisse pas faire plus aisément en PHP…

En ce qui concerne les spécifications de langage pur, PHP en a donné: http://fr3.php.net/manual/fr/userlandnaming.php, elles sont simples mais suffisent largement ! L’intérêt de ne pas trop en imposer est aussi de pouvoir laisser au chefs de projet à la direction technique de décider des conventions de code.

Comprenez bien que je trouve justement que PHP est plus adapté au développement Pro pour ces raisons. Java a tout à fait sa place mais ce genre de comparaison n’a, selon moi, pas lieu d’être. Il faut juste prendre l’outil adapté et respecter des standards, **quelque soit le langage…** alors pourquoi tant se prendre la tête sur ce sujet ?