[spip-dev] bug du compilo pour les boucles recursives (?)

fil · Novembre 11, 2005, 7:28

Je fais :

<BOUCLE_hComment(FORUMS){id_forum}{plat}>
#TITRE
</BOUCLE_hComment>

<BOUCLE_threads(FORUMS){id_article}{par date}{inverse}{0,10}>
<BOUCLE_appel(BOUCLE_hComment){id_forum}></BOUCLE_appel>
</BOUCLE_threads>

j'espérais ainsi que la BOUCLE_appel récupérerait l'id_forum pour m'afficher
son contenu (rôle dévolu à la boucle _hComment) ; malheureusement ce n'est
pas le cas (dixit le debug). En revanche si je mets #ID_FORUM juste devant
<BOUCLE_appel...> le select se fait bien et ma boucle _hComment affiche bien
le contenu du message.

J'en déduis donc un bug du compilo, sauf si c'est moi.

-- Fil

Mortimer_Porte · Novembre 11, 2005, 9:08

Fil wrote:

Je fais :

<BOUCLE_hComment(FORUMS){id_forum}{plat}>
#TITRE
</BOUCLE_hComment>

<BOUCLE_threads(FORUMS){id_article}{par date}{inverse}{0,10}>
<BOUCLE_appel(BOUCLE_hComment){id_forum}></BOUCLE_appel>
</BOUCLE_threads>

j'espérais ainsi que la BOUCLE_appel récupérerait l'id_forum pour m'afficher
son contenu (rôle dévolu à la boucle _hComment) ; malheureusement ce n'est
pas le cas (dixit le debug). En revanche si je mets #ID_FORUM juste devant
<BOUCLE_appel...> le select se fait bien et ma boucle _hComment affiche bien
le contenu du message.

J'en déduis donc un bug du compilo, sauf si c'est moi.

je pense que ça vient du même endroit, mais j'ai trouvé cela, je ne suis pas sûr que ce soit un bug...

<BOUCLE_rubrique(RUBRIQUES) {id_rubrique}>
<B_article>
#TITRE
<BOUCLE_article(ARTICLES) {id_article}>
#TITRE
</BOUCLE_article>

<BOUCLE_sous_rub(RUBRIQUES) {id_parent}>
<BOUCLE_repeat_art(BOUCLE_article)> </BOUCLE_repeat_art>
<BOUCLE_subsub(BOUCLE_sous_rub)> </BOUCLE_subsub>
</BOUCLE_sous_rub>

</BOUCLE_rubrique>

dans la boucle repeat_art, le titre de la rubrique n'est pas selectionné, affiché.

Pierre

esj · Novembre 11, 2005, 10:30

Non ce ne sont pas des bugs. Lorsqu'on compile un langage on doit faire un choix entre portée dite statique ou dite dynamique: dans le premier cas, on décide à la compilation de l'origine d'une variable, dans le second on ne le décide qu'à l'exécution. Le deuxième cas donne un plus grand souplesse d'écriture, mais ce qu'on écrit est alors beaucoup plus difficile à maintenir et à optimiser car la signification d'un portion de ce qu'on écrit n'est certaine qu'après avoir lu l'intégralité du texte. En l'occurrence, si j'avais choisi ce mode (récusé par tous les compilateurs du monde aujourd'hui) je n'aurais pas pu, entres autres, limiter les SELECT aux seuls champs effectivement utilisés.

Ces deux exemples ne me semblent pas remettre en cause ce choix car ils utilisent un boucle dite récursive pour un déroulé qui n'est pas récursif: leur intention est en fait de réaliser en un point du squelette une inclusion d'une boucle présente en un autre point, et pour les inclusions Spip offre un balise bien identifiée: INCLURE. Si on mélange les torchons et les serviettes, tout fout le camp.

Emmanuel

Mortimer_Porte · Novembre 11, 2005, 10:41

Déesse A. wrote:

fil · Novembre 11, 2005, 10:53

réaliser en un point du squelette une inclusion d'une boucle présente en
un autre point

C'est la technique utilisée dans le dist/backend.html

Ca a l'avantage de permettre d'écrire des squelettes bien "propres" avec
l'équivalent de "sous-procédures".

et pour les inclusions Spip offre un balise bien identifiée: INCLURE.

Pas faux ; ce qui appelle deux remarques :
- l'inclusion ici est "statique", et pas "dynamique" (comme celle que fait
INCLURE), et SPIP n'offre pas (pas encore ?) de mécanisme pour cela.
- l'intérêt d'avoir des éléments dans un même squelette, c'est que ça permet
de rester lisible.

Bon, je vais voir à utiliser la technique d'INCLURE dans hBones, pour être
sérieux ; en l'occurrence ça peut se justifier d'avoir une "noisette" pour
chaque message de forum affiché.

Si on mélange les torchons et les serviettes, tout fout le camp.

C'est écrit dans le Ginette Mathiot

-- Fil

esj · Novembre 11, 2005, 11:14

réaliser en un point du squelette une inclusion d'une boucle présente en
un autre point

C'est la technique utilisée dans le dist/backend.html

Oui je sais, on avait traité ce cas précis (plus simple) par souci de compatibilité, mais je suis pour l'éliminer car ça laisse croire que les autres sont possibles.

Ca a l'avantage de permettre d'écrire des squelettes bien "propres" avec
l'équivalent de "sous-procédures".

Non justement ce n'est pas propre, parce qu'on ne sait pas à quelles boucles font référence les champs à l'intérieur de la boucle "récursive" mais non définis par elle. Les sous-procédures sont toujours déclarées syntaxiquement à l'intérieur des procédures dont elle empruntent les variables. Si on veut faire des références externes, alors il faut utiliser une déclaration type "global" qui existe en PHP mais pas en Spip. Le seul langage qui permettait de s'en dispenser était Lisp, mais il a disparu exclusivement à cause de ce choix (car à part ça il était à cent coudées au-dessus de tous les autres). Je n'ai pas envie que Spip suive le meme chemin.

et pour les inclusions Spip offre un balise bien identifiée: INCLURE.

Pas faux ; ce qui appelle deux remarques :
- l'inclusion ici est "statique", et pas "dynamique" (comme celle que fait
INCLURE), et SPIP n'offre pas (pas encore ?) de mécanisme pour cela.

Elle n'a rien de statique puisque dépendant du moment de l'exécution. Il suffit d'avoir des délais égaux pour avoir le meme comportement avec INCLURE qu'avec un seul squelette.

- l'intérêt d'avoir des éléments dans un même squelette, c'est que ça permet
de rester lisible.

Pas d'accord. Si je n'ai qu'une occurrence d'utilisation d'un boucle, ce qui est lisible (et plus performant) c'est de la mettre à l'endroit où elle executée, donc à l'intérieur des balises de boucles qu'elle référence. Si j'en ai plusieurs, ce qui est lisible c'est d'en faire un squelette à part inclus en plusieurs endroits pour montrer tout de suite que c'est bien le meme code.

Bon, je vais voir à utiliser la technique d'INCLURE dans hBones, pour être
sérieux ; en l'occurrence ça peut se justifier d'avoir une "noisette" pour
chaque message de forum affiché.

Si on mélange les torchons et les serviettes, tout fout le camp.

C'est écrit dans le Ginette Mathiot

Comme quoi les memes lectures ne conduisent pas nécessairement à la meme gastronomie !

Emmanuel

fil · Novembre 11, 2005, 11:28

Non justement ce n'est pas propre, parce qu'on ne sait pas à quelles
boucles font référence les champs à l'intérieur de la boucle
"récursive" mais non définis par elle.

Dans mon exemple j'ai pourtant bien explicitement passé le paramètre :
<BOUCLE_appel(BOUCLE_hComment){id_forum}>

Mais effectivement c'est peut-être une autre notion d'inclure qui devrait
être prise, car le besoin d'une "boucle_appel" montre bien que ce que je
fais n'est pas propre.

Ce que je veux faire, c'est plutôt quelque chose qui intuitivement serait :
<INCLURE(BOUCLE_hComment){id_forum}>

Mais effectivement en mettant la boucle _hComment dans un squelette externe
ça marche aussi (et, en l'occurrence, ça permet de faire une jolie
"noisette", qui permet à quelqu'un de modifier l'apparence d'un post de
forum sans toucher la structure arborescente, ou vice-versa).

>Pas faux ; ce qui appelle deux remarques :
>- l'inclusion ici est "statique", et pas "dynamique" (comme celle
>que fait
> INCLURE), et SPIP n'offre pas (pas encore ?) de mécanisme pour cela.

Elle n'a rien de statique puisque dépendant du moment de l'exécution.

Comment ça ? Le squelette donne toujours le même résultat, je ne comprends
pas ce que tu veux dire.

Il suffit d'avoir des délais égaux pour avoir le meme comportement
avec INCLURE qu'avec un seul squelette.

Je ne crois pas, non (car un même cache peut avoir été "inclus" à partir de
plusieurs pages) ; mais ce n'est pas vraiment le sujet, il me semble.

Par ailleurs l'INCLURE fait du php (tu sais, celui que tu voulais éliminer).
Je ne dis pas que c'est un problème, hein.

-- Fil

esj · Novembre 11, 2005, 11:40

Non justement ce n'est pas propre, parce qu'on ne sait pas à quelles
boucles font référence les champs à l'intérieur de la boucle
"récursive" mais non définis par elle.

Dans mon exemple j'ai pourtant bien explicitement passé le paramètre :
<BOUCLE_appel(BOUCLE_hComment){id_forum}>

C'est la définition de la boucle récursive qui est ambigu, pas son appel: en portée dynamique on ne peut savoir si son #TITRE référence un forum, un article, un mot etc. Et c'est ça qui dégrade sa compilation.

Elle n'a rien de statique puisque dépendant du moment de l'exécution.

Comment ça ? Le squelette donne toujours le même résultat, je ne comprends
pas ce que tu veux dire.

je veux seulement dire ci-dessus: l'origine de #TITRE n'apparait qu'à l'exécution.
Evidement, un compilateur qui analyserait tout ce texte pourrait l'assembler différement. Mais c'est indécidable dans le cas général.

Il suffit d'avoir des délais égaux pour avoir le meme comportement
avec INCLURE qu'avec un seul squelette.

Je ne crois pas, non (car un même cache peut avoir été "inclus" à partir de
plusieurs pages) ;

oui mais je supposais un simple éclatement de l'original, sans réutilisation à part.

mais ce n'est pas vraiment le sujet, il me semble.

Par ailleurs l'INCLURE fait du php (tu sais, celui que tu voulais éliminer).

C'est un choix d'implémentation qu'on pourrait traiter autrement (je l'avais fait d'ailleurs): ce n'est pas imposé par la sémantique elle-même.

Je ne dis pas que c'est un problème, hein.

Disons qu'il y en a de plus urgent

Emmanuel