PHP 5.3 : Ce qui n'est pas pour tout de suite... Peut-être pour plus tard ?

Avant de terminer cette série d'articles sur les nouveautés de PHP 5.3, je me suis dit qu'il pourrait être << marrant / intéressant >> de parler de quelques points qui ont été évoqués pendant le développement de cette nouvelle version, et qui n'ont finalement pas été retenus... Ainsi que de jeter un très bref coup d'oeil à ce que pourrait nous réserver l'avenir.

Sommaire :

• Syntaxe << JSON-like >> pour les déclarations de tableaux ? Non !
• __getStatic & __setStatic ? Non !
• Et quid de PHP 6 ?
  • Quelques modifications prévues pour PHP 6
  • PHP 6 : Conservations
• PHP 5.3 == PHP << 5.et-demie >> ?

Syntaxe << JSON-like >> pour les déclarations de tableaux ? Non !

Un patch avait été posté sur internals@ début 2008, proposant deux nouvelles syntaxes << raccourcies >> de déclaration de tableaux, inspirée de la syntaxe généralement utilisée en Javascript : [RFC] Square brackets shortcut.

Plutôt que de définir un tableau de la manière suivante, qui existe depuis à peu près toujours :

<?php
$a = array(1, 2, 3);
$b = array('foo' => 'orange', 'bar' => 'apple', 'baz' => 'lemon');
var_dump($a, $b);

Il était envisagé de permettre l'utilisation de cette syntaxe alternative :

<?php
$a = [1, 2, 3];
$b = ['foo': 'orange', 'bar': 'apple', 'baz': 'lemon'];
var_dump($a, $b);

Ou de se rabattre sur une syntaxe intermédiaire, reprenant à la fois les << [] >> de Javascript, et les << => >> de PHP :

<?php
$a = [1, 2, 3];
$b = ['foo' => 'orange', 'bar' => 'apple', 'baz' => 'lemon'];
var_dump($a, $b);

Ceux qui ont l'occasion de travailler en Javascript, et, éventuellement, de manipuler des données au format JSON, verront d'où est venue l'inspiration ^^

Et bien, aucune de ces propositions n'a été retenue : la première portion de code lèvera une Parse Error :

... De même que la seconde :

Nous aurions gagné quelques caractères... Et certainement perdu en lisibilité... Et aucune de ces syntaxes n'était dans << l'esprit de PHP >>.
Tant pis, donc ^^

__getStatic & __setStatic ? Non !

Nous utilisons parfois, depuis PHP 5, les méthodes magiques __get, __set et compagnie pour accéder à des propriétés d'objets de nos classes, n'existant pas lors de la définition de celles-ci.

Par exemple, le code suivant :

<?php
class A {
    protected $_store = array();
    public function __get($name) {
        var_dump("__get($name)");
        if (isset($this->_store[$name])) {
            return $this->_store[$name];
        }
        return null;
    }
    public function __set($name, $value) {
        var_dump("__set($name, $value)");
        $this->_store[$name] = $value;
    }
}

$a = new A();
$a->maValeur1 = 10;
var_dump($a->maValeur);

Donnerait la sortie écran suivante :

string '__set(maValeur1, 10)' (length=20)
string '__get(maValeur)' (length=15)
null

Les utilisations de variables de classes inexistantes sont interceptées par les méthodes __get et __set.

Nous avons vu au cours d'un article précédent que PHP 5.3 introduisait la méthode magique __callStatic.

Nous aurions donc pu penser que les méthodes __getStatic, __setStatic, __issetStatic, et __unsetStatic feraient leur apparition, et qu'il deviendrait possible d'accéder à des attributs statiques de classes, sans les déclarer -- un peu comme ceci :

<?php
class A {
    public static function __getStatic($name) {
        var_dump("__getStatic($name)");
    }
    public static function __setStatic($name, $value) {
        var_dump("__setStatic($name, $value)");
    }
}

// Fatal error: Access to undeclared static property: A::$maValeurStatique
A::$maValeurStatique = 10;
var_dump(A::$maValeurStatique);

Et bien... Non, ce n'est pas possible : cette portion de code entraine une Fatal Error :

Ce sujet de discussion est revenu plusieurs fois sur internals@ au cours des derniers mois... Peut-être pour une prochaine version, donc ? Qui sait ?

A ce sujet, vous pouvez d'ailleurs, par exemple, jeter un œil sur :

• Request for Comments: Static classes for PHP

Et quid de PHP 6 ?

Difficile de penser à l'avenir de PHP sans penser à PHP 6 : sa date de sortie n'est pas définie, la listes fonctionnalités qui seront ajoutés n'est pas finale, de même que celle des points qui disparaitront... Mais des changements sont prévus !

Le projet PHP 6 a été lancé en 2006, il y a bien deux ans maintenant, et des snapshots des sources sont téléchargeables régulièrement depuis snaps.php.net.
Pour ce qui est de la compilation et de l'installation, je vous laisse vous inspirer de ce que nous avons eu l'occasion de faire plus haut pour PHP 5.3 : il n'y a pas de grosse différence entre les processus d'installation de ces deux version -- et si vous rencontrez des erreurs au configure ou au make, elles seront probablement assez explicites pour que vous puissiez les corriger d'une façon ou d'une autre ;-)

J'ai compilé un snapshot de PHP 6 aux environs d'avril/mai 2008, et un autre il y a une paire de semaines ; dans les deux cas, je n'ai pas rencontré de problème particulier, et j'ai pu faire tourner cette future-nouvelle version ; libre à vous de vous amuser avec, donc !

Quelques modifications prévues pour PHP 6

Pour ne citer que certaines des modifications prévues, en vrac :

• Support à 100% de l'Unicode, que ce soit au niveau des fichiers sources, des flux d'entrées/sortie, dans le moteur, les extensions, ...
  • Pour la liste des fonctions actuellement compatibles unicode, vous pouvez faire un tour sur http://www.php.net/~scoates/unicode/render_func_data.php ; actuellement, nous en sommes à presque 70 % !
  • Cela n'a pas beaucoup progressé ces derniers temps... Mais PHP 5.3 a attiré beaucoup d'attention, qui ne s'est pas portée sur PHP 6, pendant ce temps...
  • En parallèle, apparition des notions d'<< octet >> et de << caractère >>.
• Ajout de nouvelles fonctionnalités de manipulation de texte -- des itérateurs, par exemple, capables d'itérer sur un texte mot par mot, en tenant compte de la locale courante !
• Ajout de nouvelles fonctions, en particulier pour manipuler tout ce qui est chaines unicode
• Ajout d'un nouveau type << int64 >> pour les entiers, qui pourraient alors être codés spécifiquement sur 32 bits lorsque c'est nécessaire.
• Augmentation du nombre de tests unitaires portant sur le moteur de PHP
  • En les jouant tous dans une version << non-unicode >>, et en version << unicode >> !
• Déplacement de fonctionnalités de la distribution << par défaut >> vers PECL
  • Ces extensions seraient donc toujours existantes et disponibles,
  • Mais moins maintenues -- à noter que les extensions ciblées ne sont déjà pas très vivantes aujourd'hui !
  • Au niveau des extensions potentiellement déplacées vers PECL, on peut penser à ereg, ncurse, mime_magic, ... Le travail a d'ailleurs commencé en PHP 5.3, avec l'ajout du niveau de reporting d'erreur E_DEPRECATED !
• Suppression d'options de configuration -- et des << fonctionnalités >> qui vont avec :
  • register_globals -- désactivée par défaut depuis PHP 4.2.0 en avril 2002 -- va enfin disparaitre !
  • safe_mode, qui donne uniquement un << faux >> sens de sécurité
  • magic_quotes -- ça aussi, ça ne fera pas de mal !
  • register_long_arrays -- Cela fait bien longtemps que les tableaux HTTP_*_VARS ont été remplacés par les super-globales _GET, _POST, et autres...

PHP 6 : Conservations

Quelques points seront probablement conservés, même si c'est parfois discutable :

• PHP 6 n'intègrera toujours pas de débugger en natif :-(
  • Utilisez Xdebug, par exemple !
• Les noms de fonctions << inconsistants >>^[1] le resteront : la politique est de conserver l'existant, tout en essayant de ne pas continuer à empirer la situation pour les futurs ajouts
• Les noms de fonctions restent insensibles à la casse.
  • Ca aussi, c'est un sujet qui revient de temps en temps sur internals@ ^^
• Toujours pas de try ... catch ... finally
• Pas d'héritage multiple non plus
  • Mais peut-être des fonctionnalités d'import << horizontal >> de code
  • Cf par exemple Request for Comments: Traits for PHP
• On disait à un moment que PHP 6 intègrerait APC ; il semblerait finalement que ça ne soit pas le cas.

Pour vous tenir au courant, n'hésitez pas à suivre la mailing-list internals@ ; elle parle beaucoup de PHP 5.3 en ce moment -- et ça semble normal -- mais dans quelques temps, qui sait ;-)

Et, d'ici un an ou deux, au moment de la sortie de PHP 6, qui sait si quelqu'un ne rédigera pas une série d'articles, comme je l'ai fait pour PHP 5.3 ? %)

Quoi qu'il en soit, mon côté << curieux >> attend PHP 6 avec une certaine impatience... Même si ce n'est pas pour tout de suite, et que ce n'est certainement pas demain qu'il sera répandu, tant sur les hébergements grand publics que pour les projets professionnels d'envergure...
(Déjà, avant PHP 6, il faudrait pouvoir développer en PHP 5.3 en se disant que notre application fonctionnera sur à peu près n'importe quel serveur ^^)

PHP 5.3 == PHP << 5.et-demie >> ?

Au fur et à mesure que la sortie de PHP 5.3 était repoussée et que celle de PHP 6 ne semblait pas se rapprocher, des fonctionnalités initialement prévues pour PHP 6 ont été intégrées à PHP 5.3 ; pour ne citer que quelques exemples, je pense notamment à mysqlnd, ou à l'instruction goto.

Finalement, PHP 5.3 semble presque être une version << majeure >>, en termes de fonctionnalités, et est parfois considérée comme une version << 5.et-demie >> ^^

Pourquoi ne pas avoir changé de version majeure, alors ? Parce que les nouveautés introduites en PHP 5.3 ne sont censées avoir que peu d'impacts potentiels sur le code qui fonctionnait en PHP 5.2 : en dehors de quelques classes et fonctions ajoutées^[2], peu de choses ont changé, même si les nouveautés sont nombreuses !

J'ajouterai qu'un changement de version majeure d'un outil fait << peur >> : << si le numéro de version majeur change, c'est surement qu'il y a des modifications extrêmement importantes... S'il y a des modifications aussi importantes, est-ce que cela ne risque pas de casser mes applications, qui fonctionnent actuellement sans problème ? Donc, il vaudrait peut-être mieux ne pas passer à la version supérieure ! Et pour les nouveaux projets ? Puisqu'ils seront hébergés sur les mêmes machines, ou que nous ne voulons/pouvons pas administrer deux plates-formes de versions différentes, les nouveaux projets doivent aussi utiliser l'ancienne version ! >>.
Lequel d'entre nous ne connait pas ce raisonnement ?

Et pourquoi attendre PHP 6 pour passer à un support full-unicode ? Probablement parce que les impacts sur le moteur sont tellement importants que, là, il y aura réellement des risques non négligeables ^^