[spip-dev] |reset et |end

bonjour,

( je reviens dessus, déjà abordé :
   http://thread.gmane.org/gmane.comp.web.spip.devel/56024 )

les deux filtres |reset et |end, appliquables à un tableau
permettent de ne pas énerver le débusqueur pour un passage
par référence malvenu (ce que feraient les fonctions originales
PHP end(&$array) et reset(&$array)...

de plus ces 2 filtres testent préalablement la réalité de
l'array passé en premier $arg.
bien.

il se trouve que pour une raison qui m'échappe, ces 2 filtres
ne remplissent pas du tout les mêmes fonctions que leurs
homonymes php-esques :

   #SET{tableau, #ARRAY{8,a, 2,b, 5,c, 3,d, 0,e, 1,f}}
   [reset : (#GET{tableau}|reset)<br />] retourne * e *
   [end : (#GET{tableau}|end)] retourne * c *

   <?php
   $tableau = array(8=>'a',2=>'b',5=>'c',3=>'d',0=>'e',1=>'f');
   echo 'reset : ' . end($tableau) . // retourne * f *
        '<br />end : ' . reset($tableau); // retourne * a *
   ?>

ces filtres ne sont utilisés que pour le calcul des bornes
des paginations et *une* fois dans *le* plugin export_odt/spipoasis.html
(j'ai scanné toute la zone pour chercher)

ne serait-il pas judicieux de les remplacer par :

// http://doc.spip.org/@filtre_reset
function filtre_reset($array) {
- return filtre_valeur_tableau($array,0);
+ return !is_array($array) ? null : reset($array);
}
// http://doc.spip.org/@filtre_end
function filtre_end($array) {
- return filtre_valeur_tableau($array,@count($array)-1);
+ return !is_array($array) ? null : end($array);
}

Tout a fait d'accord, je ne sais pas quelle est la raison cachée qui a
conduit à les écrire en se basant sur l'index, mais avoir un
comportement différent des reset et end de php est plus que trompeur.
Au pire, si nécessaire, il sera toujours temps de faire 2 filtres
autrement nommés qui se comportent en fonction de l'index uniquement.

Donc ok pour moi pour corriger cela dans la branche 2.1 et dev.
Cédric

Pour ma part, c'est autre chose qui me gène avec ces filtres, comme avec «implode» et «explode», c'est l'ordre des arguments qui changent par rapport à PHP. Je sais bien que c'est voulu justement, mais je trouve ça très gênant : déjà que PHP est pas royal sur l'ordre des arguments entre ses différentes fonctions, si on ajoute en plus que SPIP en modifie certaines pour sa convenance, ça devient un calvaire de connaitre, pour telle fonction utilisée, l'ordre correct attendu.

Je préfèrerais que ces fonctions qui changent cet ordre aient un autre nom, par exemple en étant francisés. Il y aurait moins de mystère : anglais = php, français = spip (et ordre inverse à php).

Bref, je ne trouve pas ça très bon d'avoir des exceptions de la sorte. Au pire, il vaudrait mieux faire comprendre au compilateur l'équivalent de #|reset{tableau}, ce serait plus clair pour tout le monde.

déjà que PHP est pas royal sur l'ordre des arguments entre
ses différentes fonctions, si on ajoute en plus que SPIP en modifie
certaines pour sa convenance, ça devient un calvaire de connaitre, pour
telle fonction utilisée, l'ordre correct attendu.

on sait que les filtres de spip prennent pour premier argument la balise
à laquelle ils s'appliquent.

pour le cas de |reset et |end, ce me semble suffisant.

pour |implode et |explode, on peut noter que, en ce qui concerne la
fonction php implode(), l'ordre des arguments est indifférent (même si
conseillé...) ; pour explode(), ma foi...

je crois pour le coup qu'il faut respecter la cohérence de spip pour ce
qui est de ses filtres : 1er argument -> BALISE à gauche du |
(|explode serait sinon *la* exception -de spip-)

Je préfèrerais que ces fonctions qui changent cet ordre aient un autre
nom, par exemple en étant francisés. Il y aurait moins de mystère :
anglais = php, français = spip (et ordre inverse à php).

alors là, comme ce sont des fonctions homonymes de php (dont on vient
justement de calquer le fonctionnement), je suis vraiment pas pour leur
donner un nom différent (à la limite, c'est avant leur correction
qu'elles auraient dû s'appeler différemment ; mais plus maintenant)

il vaudrait mieux faire comprendre au compilateur l'équivalent
de #|reset{tableau}, ce serait plus clair pour tout le monde.

je passe...

on sait que les filtres de spip prennent pour premier argument la balise
à laquelle ils s'appliquent.

Oui, ça on le sait, et on connait aussi l'ordre des arguments des fonctions PHP. Jusque là, tout va bien.

Ce qui me déplait, c'est de dire que pour certains filtres, SPIP surcharge la fonction native de PHP, avec un filtre homonyme, pour inverser les 2 premiers arguments.

Pourquoi dans ce cas |implode et |explode, et pas |array_key_exists,

array_search ... qui n'ont pas le tableau en premier argument ?

Je crois qu'il faut vraiment éviter de mettre des exceptions comme ça, que ça crée plus d'embrouilles que ça ne tente d'en résoudre...

Certes le cerveau a une capacité de mémorisation quasi illimité, mais tout de même, je ne pense pas que ce soit la peine de l'utiliser pour ça... Y a peu de personnes qui aiment les verbes irréguliers quand ce n'est pas la langue maternelle :stuck_out_tongue:

Il est vrai qu'implode et explode c'est très pénible !

Avant que ces filtres n'arrivent dans Spip 1.9.2 (?) j'utilisais déjà
ces fonctions php comme filtre dans mes squelettes (avec le array en
second argument). Désormais, je suis contraint à une réécriture
pénible des squelettes parce qu'on s'est amusé à garder le même nom de
filtre en changeant l'ordre des arguments...
Et croyez moi, ces corrections son vraiment pénibles à faire (du coup
j'ai opté pour des filtres php_explode et php_implode qui reproduisent
le comportement de php et je fais un chercher/remplacer massif... Pas
très classe, ni très smart...)

Ça me paraissait plus logique dès le départ d'introduire les nouveaux
filtres avec des noms du genre spip_explode/spip_implode ce qui ne
cassait pas l'existant, tout en apportant une amélioration (parce que
c'est vrai que les arguments dans le sens de Spip c'est plus pratique
et lisible dans les squelettes).

Trop tard...

sur irc, cerdic proposait |en_table (pour |explode)
et |en_chaine (pour |implode)

ce qui, disait-il, donne l'avantage de comprendre d'où vient
le premier argument : [(#TITRE|en_table{' '})]

Ah oui, c'est joli comme ça ! Encore une bonne idée de Cédric !

Fri, 29 Jan 2010 17:51:31 +0100, denisb:

sur irc, cerdic proposait |en_table (pour |explode)
et |en_chaine (pour |implode)

Attention : pour |en_chaine, l'usage pourrait être plus générique:
écrite un objet quelconque sous forme de chaîne (comme toString en
Java). Donc si on veut une fonction limitée aux tableaux, c'est dommage
de "griller" ce nom. Ceci dit, là comme ça, en SPIP/PHP je ne vois pas
d'autre type non-chaîne qu'on pourrait avoir envie d'afficher comme
chaîne, donc peut-être que ça sera jamais un souci.

Même chose pour |en_table, bien que là ça me semble carrément théorique
de vouloir transformer autre chose qu'une chaîne en tableau.

M'enfin ça vaut le coup de se poser la question (une fois qu'un nom est
utilisé c'est pour la vie).