Ben moi je suis persuadé du contraire. Si ces deux entites renvoient la même chose, c'est qu'une d'entre elles est de trop. Au vrai, #INCLURE a été rajouté pour des raisons de performances, ce qui veut dire un aveu d'impuissance de la part du compilateur qui ne sait pas tout seul choisir ce qui est mieux. Avec cette modif, on retombe sur la distinction habituelle entre procédure et macro dans un langage compilé: dans le cas de la macro on garantit qu'il n'y a rien d'inséré dans le code avant l'appel de la macro (cas #INCLUDE), avec la procédure on sait qu'il peut y avoir des choses (cas <INCLURE.).
J'ajoute que ce chgt pour #INCLURE a pour effet de corriger réelle limitation de SPIP: l'impossibilité d'avoir un critère lang condtionnel dans une inclusion, ce qui en fait était un argument pour ne pas le mettre d'office dans <INCLURE>. Ca a paru plus pratique de le faire quand même à l'époque, on peut éventuellement en discuter aujourd'hui, mais il y a beaucoup de squelette qui comptent là-dessus pour <INCLURE>. Changer #INCLURE, d'introduction plus récente, me semble donc la solution la moins perturbante pour à la fois élimliner cette limitation et garantir une compatibilité presque complète.
C'est très embetant cela : #INCLURE et <INCLURE> *doivent* renvoyer le meme résultat quels que soient leurs parametes, et dans tous les cas, seule la mise en cache étant différente.
Je crois que le passage auto de la lang avait été ajouté par fil, je ne saurais pas argumenter pourquoi.
En revanche, ce dont je suis sur, c'est qu'on le passe partout ou nulle part, et qu'il faut garder l'identité entre #INCLURE et <INCLURE>
Ben moi je suis persuadé du contraire. Si ces deux entites renvoient la même chose, c'est qu'une d'entre elles est de trop. Au vrai, #INCLURE a été rajouté pour des raisons de performances
non, juste pour pouvoir faire
[(#INCLURE{fond=xxxx}|monfiltre)]
c'est à dire appliquer un traitement à du contenu produit par une inclusion.
Les aspects performances et cache en ont juste découlé, et leur distinction a une vrai utilité.
, ce qui veut dire un aveu d'impuissance de la part du compilateur qui ne sait pas tout seul choisir ce qui est mieux. Avec cette modif, on retombe sur la distinction habituelle entre procédure et macro dans un langage compilé: dans le cas de la macro on garantit qu'il n'y a rien d'inséré dans le code avant l'appel de la macro (cas #INCLUDE), avec la procédure on sait qu'il peut y avoir des choses (cas <INCLURE.).
J'ajoute que ce chgt pour #INCLURE a pour effet de corriger réelle limitation de SPIP: l'impossibilité d'avoir un critère lang condtionnel dans une inclusion, ce qui en fait était un argument pour ne pas le mettre d'office dans <INCLURE>. Ca a paru plus pratique de le faire quand même à l'époque, on peut éventuellement en discuter aujourd'hui, mais il y a beaucoup de squelette qui comptent là-dessus pour <INCLURE>. Changer #INCLURE, d'introduction plus récente, me semble donc la solution la moins perturbante pour à la fois élimliner cette limitation et garantir une compatibilité presque complète.
C'est toi qui vois, mais je pense que la distinction entre <INCLURE> et #INCLURE va devenir très obscure pour le commun des spipeurs, surtout si elles sont susceptibles de produire un résultat différent
Au vrai, #INCLURE a été rajouté pour des raisons de performances
, ce qui veut dire un aveu d'impuissance de la part du compilateur
non, juste pour pouvoir faire
[(#INCLURE{fond=xxxx}|monfiltre)]
c'est à dire appliquer un traitement à du contenu produit par une inclusion.
Bon, soit, mais alors c'est un autre aveu d'impuissance: celui de ne pas pouvoir appliquer un traitement sur autre chose qu'une balise.
..
leur distinction a une vrai utilité.
...
C'est toi qui vois, mais je pense que la distinction entre <INCLURE> et #INCLURE va devenir très obscure pour le commun des spipeurs, surtout si elles sont susceptibles de produire un résultat différent
Pour moi c'est plutot avant qu'elle était obscure, et c'est maintenant que "leur distinction a une vrai utilité." !
