Bonjour
J'ai proposé un ticket hier soir sur common/lib.crypt.php justement
(#1534). Le plus simple pour faire évoluer en douceur est justement les
polyfill (terme que je ne connaissais pas) à grand coup de
function_exists et de class_exists :
if (function_exists('method_native'))
{
method_native($argument);
}
Souvent les méthodes natives sont plus rapides car écrites en C. Dans le
cas de crypt::hmac vs hash_hmac c'est un facteur de 12.
Sinon :
1) Bonne question. Quelle est la version minimum pour clearbreaks ?
2) Je ne peux pas juger sur qui utilise clearbreaks et avec quelle
version de PHP. Mais je pense que viser a v5.3 n'est pas totalement
stupide. Même debian fourni en stable la v5.4.4 et en squeeze la v5.3.3
La plupart des fonctions citées sont dépréciées depuis PHP v5.2.
3) On peut rester un paquet de temps avec *_exists() jusqu'à ce que
cette fonction soit elle même dépréciée mais ça oblige à de la
maintenance supplémentaire.
Par ailleurs la plupart des loueurs d'hébergements proposent plusieurs
versions de PHP (comme lostoasis chez qui je suis hébergé). J'en ai même
trouvé un qui propose la v4.4.9 !
Ma position est simple. On avance en prenant en compte l'ancien tant que
c'est possible.
L'avenir de PHP est clairement fonctionnel (closure) comme d'ailleurs la
plupart des langages importants que je vois, et sa pleine expression est
PHP 5.4... Il n'y a qu'à voir des trucs comme Lavarel pour s'en rendre
compte. Cet aspect _doit_ être pris en compte autant que possible. Rien
n'empêche de faire évoluer en douceur cet aspect. On pourrait, dans
certaines fonctions où cela est pertinent écrire :
function maFonction($argumentsNormaux, $callback=null)
{
if (function_exists('methode_native')) {
$resultat = methode_native($argumentsNormaux);
} else {
// polyfill
}
if (is_callable($callback)) {
$callback($erreur, $resultat);
} else {
return $resultat;
}
}
D'ailleurs, comme mon hébergement utilise 5.4, je n'hésite pas à écrire
pour mes templates dotclear non diffusées :
$core->addBehavior('trucMachin', function() {
machintruc();
});
Et je ne parle pas encore des namespace (trop tôt : PHP 5.3 et sup).
Voilà voilà.
On 15/08/2013 01:17, Denis Jean-Christian wrote:
Bonjour, bonsoir,
J'ai vu plusieurs PR, messages, etc, parlant de fonctions à remplacer
dans Clearbricks par leurs pendant en PHP natif, je souhaiterais lancer
un grande (ou pas) discussion qui je le pense va être mouvementée, mais
c'est le but.
Voici mes premières questions :
1) Quelle est politique à propos de Clearbricks, a-t-on les pleins
pouvoir sur la branche default, car bien que essentiellement utilisée et
hébergée (tout comme) par Dotclear, elle n'en fait pas vraiment partie
et d'autres personnes l'utilisent.
2) L'avantage de Clearbricks est qu'elle fonctionne sur quasi tous les
serveurs, c'était d'ailleurs son but premier. Le temps de retard qu'elle
a par rapport aux innovations PHP n'est-elle pas un avantage ? (hormis
les deprecated comme modifier PCRE \e, mysql vs mysqli, etc)
3) Des messages sont également passés disant "la suite c'est de s'en
séparer", bon OK je sais que, hum, non. z'en pensez ?
D'autres questions peuvent suivre, c'est ouvert :-)
Cordialement,
JcDenis
--
Dev mailing list - [email protected] - http://ml.dotclear.org/listinfo/dev
