Les nouveautés en POO

Tout le monde est d’accord avec ça: la Programmation Orientée Objet est actuellement le point faible de PHP par rapport à ces concurrents. En effet, cet aspect incontournable du développement n’est implémenté dans PHP que depuis peu de temps. Voilà pourquoi la POO dans PHP n’est pas encore idéale. Bien évidement, PHP6 est l’occasion de pas mal de nouveautés de ce coté …

Les espaces de noms (ou namespaces)

Dans la POO de PHP6, la grande nouveauté sera l’apparition des espaces de noms (ou namespaces). Cette fonctionnalité est déjà présente dans PHP 5.3 sous la forme d’un patch. En fait, ce n’est pas vraiment innovation puisque tout les langages de haut niveau implémentent déjà les namespaces (Java, C#, Python, …).

Il s’agit de pouvoir regrouper toute une série de classes sous une seule et unique entité. Cela encourage ouvertement le développement de classes sous formes de frameworks. Maintenant, plus besoin de préfixer le nom de ses classes (comme on le faisait jusque là). Par exemple: monAplication_Parser et monAutreAplication_Parser. Pour illustrer clairement l’implémentation des namespaces, reprenons la démonstration de Dmitry Stogov (l’initiateur de l’idée):

namespace Zend::DB; 
 
class Connection {
} 
 
function connect() {
}

require 'Zend/Db/Connection.php';
import Zend::DB;
import Zend::DB::Connection as DbConnection; 
 
$x = new Zend::DB::Connection();
$y = new DB::connection();
$z = new DbConnection(); 
 
DB::connect();

L’obligation d’appeler le constructeur parent

Imaginez que vous développiez une classe qui sera héritée, par la suite, par des classes crées par des développeurs tiers. Maintenant, imaginons que vous faisiez des initialisations cruciales dans votre constructeur (par exemple se connecter à une base de données). Donc, si le constructeur n’est pas appelé, vos requêtes ne pourront pas êtres faites par la suite (votre classe tombe donc).

Créer un objet sans faire appel à un constructeur: « Quelle idée ? » me direz vous … Oui mais si la classe est héritée par une autre classe qui, elle, définit un constructeur, alors le constructeur de la classe mère ne sera jamais appelé. Pour pallier à ce problème, la décision a été prise d’implémenter un flag dans PHP6. Celui-ci servira au développeur de la classe mère à indiquer au moteur PHP que le constructeur de sa classe doit être appelé dans tout les cas. On ne sait pas, pour le moment, la forme que prendra ce flag.

Les retours de méthodes typés

PHP n’est pas véritablement ce que l’on peut appeler un langage typé. En effet, on peut travailler avec des variables sans véritablement se soucier de ce qui se trouve dedans (int, string, double, …). Certes, ça à de gros avantages en terme de simplicité. Mais en terme de développement, le typage est quelque chose qui, quand on est habitué, est quasiment indispensable.

Bien évidement, il n’est pas question pour le PHP Group de rendre PHP6 typé (« it’s just generally not-PHP style » disent-ils). Mais dans les points les plus cruciaux, il serait bon de pouvoir préciser le type … C’est pourquoi PHP6 devrait permettre de préciser le type de retour des méthodes. Pour le moment, il y a une hésitation entre 3 syntaxes:

function &leType laFonction();
 
leType function &laFonction();
 
function &LaFonction() returns leType;

Notez que l’idée de pouvoir typer les paramètres d’une méthode a aussi été discutée. Il a été décidé que ce ne serait pas implémenté.

Appel de membres: la fin du mélange statique / dynamique

Actuellement, avec PHP on peut appeler un membre statique de façon dynamique. A l’inverse, un membre dynamique peut être appelée de façon statique. Prenez l’exemple du code suivant:

class zioup
{
	static function methodeStatique($a)
	{
		echo "Je suis la méthode statique et j'ai été appelée en ".$a;
	}
    function methodeDynamique($a)
	{
		echo "Je suis la méthode dynamique et j'ai été appelée en ".$a;
	}
}
 
zioup::methodeStatique("statique");
zioup::methodeDynamique("statique");
 
$zioup = new zioup;
$zioup->methodeStatique("dynamique");
$zioup->methodeDynamique("dynamique");
/* Resultat:
Je suis la méthode statique et j'ai été appelée en statique.
Je suis la méthode dynamique et j'ai été appelée en statique.
Je suis la méthode statique et j'ai été appelée en dynamique.
Je suis la méthode dynamique et j'ai été appelée en dynamique.
*/

C’est donc plutôt dangereux ! Imaginez quand dans votre méthode dynamique vous ayez besoin d’informations cruciales initialisées par le constructeur de votre classe (ex: une connexion SQL). Et bien avec l’appel statique, vous n’aurez pas fait ces initialisations ! Pour palier au problème, la décision du PHP Group est simple. L’appel d’un membre dynamique de façon statique sera interdit (en levant un E_FATAL). Concernant l’appel dynamique d’un membre statique, rien ne sera fait pour l’empêcher.