Re: Critères optionnel avec opérateur : doc imprécise ou bug?

Le 16/12/2020 à 14:11, Cerdic a écrit :
> oui mais non.
> En fait je pense que cette extension du {id_article?} initial était une 
> fausse bonne idée.
> Le fonctionnement actuel est lié à plusieurs raisons qui ne sont certes 
> pas de bonnes raisons, mais les justifications techniques :
> 
>   * au départ existait uniquement {id_article?} donc qui testait
>     implicitement l’existence d’un #ENV{id_article} et le cas échéant le
>     prenait en compte et sinon ignorait le critère
>   * l’extension sous la forme {id_article?=#ENV{truc}} est donc une
>     extension de ça et continue à tester uniquement la présence de
>     #ENV{id_article}
>   * id_article est forcément statique, et on sait quoi vérifier, c’est
>     énonçable lors de la compilation
>   * #ENV{truc} est totalement dynamique et peut aussi bien être
>     #ENV{#GET{toto}} ou #GET{truc} quoi que ce soit d’autre, autant dire
>     que "vérifier que dans le #ENV on a cette variable » n’a plus de sens
>   * a la limite il faudrait étendre avec quelque chose du genre « si le
>     membre utilisé pour la comparaison est null, on ignore la condition,
>     sinon on l’applique » car c’est ce qui s’approche le plus de « il y
>     a une variable id_article dans le env}
>   * mais voila, le compilateur est ainsi fait que l’on caste a tous les
>     etages, et je ne pense pas qu’on soit en mesure de distinguer
>     véritablement la valeur null (=pas de valeur) d’une liste vide par
>     exemple (qui doit donc retourner une selection vide) ou d’une valeur
>     zéro
> 
> Bref, il y a bug quelque part, mais peut-être à l’introduction même de 
> cette feature que je prends soin de ne jamais utiliser car trop ambigu 
> et incertaine à mon avis (sans compter que si un jour on est capable de 
> lui donner le sens attendu, ça cassera tous les usages...)
> 
> -- 
> Cédric
> Le 16 déc. 2020 à 13:47 +0100, RastaPopoulos <[email protected]>, a 
> écrit :

Merci pour cet historique, très éclairant.

J'aurais tendance à penser que sous réserve des problèmes techniques, 
ton point « si le membre utilisé pour la comparaison est null, on ignore 
la condition, sinon on l’applique » serait idéal. Par contre oui le 
problème de la conversion de type risque certainement de nous bloquer. 
Peut être ouvrir un ticket et si un jour on trouve une solution miracle 
on résoudra?

Et pour éviter de casser les usages, on pourrait imaginer un forme
{id_truc IN ?#GET{machin}}

après pour l'heure on peut se débrouiller avec le fonctionnement actuel, 
suffit de multiplier les inclusions en amont (encore que {date <? 
#ENV{borne1}} {date ?>{#ENV{borne2}}, je sais pas comment on fait)