Oui, mais ça nécessite la boucle POUR dont le statut n'est pas encore tranché
À ce propos:
Nous sommes beaucoup à trouver que les boucles de conditions (POUS,
SI, etc.) sont très pratiques. Évidement elles posent un petit
problème logico-sémantique sur la «boucle» de Spip (qui théoriquement
permet d'extraire des données de la base).
Je ne suis pas dans le secret des développeurs du core et n'arrive pas
toujours à suivre toutes les conversations ici même et sur spip-dev
mais a-t-il été envisagé une notation du genre:
<CONDITION_nom_de_la_condition (POUR){critères du pour}>
</CONDITION_nom_de_la_condition>
Ce qui évite de rendre le terme BOUCLE ambigu tout en ayant une
syntaxe connue ? Ainsi on aurait les boucle de Spip, les conditions de
Spip et les balises de Spip...
(ça reste néanmoins un peu ambigu sur les critères je le crains...)
Oui, mais ça nécessite la boucle POUR dont le statut n'est pas encore tranché
À ce propos:
Nous sommes beaucoup à trouver que les boucles de conditions (POUS,
SI, etc.) sont très pratiques. Évidement elles posent un petit
problème logico-sémantique sur la «boucle» de Spip (qui théoriquement
permet d'extraire des données de la base).
Je ne suis pas dans le secret des développeurs du core et n'arrive pas
toujours à suivre toutes les conversations ici même et sur spip-dev
mais a-t-il été envisagé une notation du genre:
<CONDITION_nom_de_la_condition (POUR){critères du pour}>
</CONDITION_nom_de_la_condition>
Ce qui évite de rendre le terme BOUCLE ambigu tout en ayant une
syntaxe connue ? Ainsi on aurait les boucle de Spip, les conditions de
Spip et les balises de Spip...
(ça reste néanmoins un peu ambigu sur les critères je le crains...)
Le 29 janvier 2009 03:58, Grégoire <gobmouch@online.fr> a écrit :
<CONDITION_nom_de_la_condition (POUR){critères du pour}>
</CONDITION_nom_de_la_condition>
Je ne vois pas la différence avec une boucle.
C'est juste une question de terminologie: BOUCLE réservé seulement à
la sélection d'éléments de la base. CONDITION, comme son nom l'indique
pour conditionner des actions.
Mais en furetant dans les archives de spip-zone, j'ai vu que la
proposition avait déjà été faite et qu'il avait été répondu que
- ça consommerait trop de regexp de faire comme ça (déjà que les
boucles en consomment pas mal)
- Cédric a fait le choix d'une implémentation simple pour Bonux, donc
de ne pas réinventer les BOUCLEs.
Mais en furetant dans les archives de spip-zone, j'ai vu que la
proposition avait déjà été faite et qu'il avait été répondu que
- ça consommerait trop de regexp de faire comme ça (déjà que les
boucles en consomment pas mal)
Certes mais on ne le fait qu'une et unique fois, ce calcul : à la
compilation. L'argument est donc un peu mou.
- Cédric a fait le choix d'une implémentation simple pour Bonux, donc
de ne pas réinventer les BOUCLEs.
Oui. Il faudrait qu'on tranche parce que ça va nous pourrir. Est-ce
qu'on prend la syntaxte moyennement logique existante, ou est-ce qu'on
crée une syntaxe propre, quitte à ce que ce soit un peu plus couteux
en calcul et en code ?
Conceptuellement consulter une base de donnée ou un tableau php je
vois pas trop la différences, dans les 2 cas on parcours des données.
Toutefois la syntaxe que propose POUR n'est pas cohérente, on indique
les donnée à boucler du coté des critéres. Donc en l'etat on casse la
grammaire d'une boucle.
Une écriture qui pourrait être intéressante ce serait
<BOUCLE_toto(TABLEAU_montableau) {criteres} ....>
C'est à dire prefixer dans les () la nature de la source de données,
mais bon ceci implique surement de modifier pas mal le compilo.
Pour SI, là je crois que c'est conceptuellement autre chose qu'un
parcours de données et du coup utiliser une BOUCLE ne semble pas
cohérent en terme de grammaire.
Pour le moment c'est un débat qui demande encore réflexion, car au
final ce n'est pas si évident que ça.
