J'imaginais ça encore plus simple et moins perturbant en lecture, déclarer
la fonction uniquement si elle n'existe pas (de toute façon la surcharge
n'étant pas autorisée en général, une erreur arriverait si elle existait
déjà en natif) :

if (!function_exists(join))
{
    function join($glue, $pieces)
    {
        return implode($glue, $pieces);
    }
}



Le 15 août 2013 08:15, Régis FLORET <[email protected]> a écrit :

> 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 <http://ml.dotclear.org/listinfo/dev>
>



-- 
Cordialement,

Frandeboeuf <nicofrand> Nicolas, http://blog.breizhogeek.com
<http://blog.breizhogeek.com>
-- 
Dev mailing list - [email protected] - http://ml.dotclear.org/listinfo/dev

Répondre à