Attention : en faisant ça tu t'obliges à implémenter complètement la
fonction native. Garder un clearbricks, qui joue plutôt le rôle de wrapper,
permet de décider de l'interface.
Le 16 août 2013 00:31, "nicofrand" <[email protected]> a écrit :
> 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
>
--
Dev mailing list - [email protected] - http://ml.dotclear.org/listinfo/dev
