[WIP] Légère evolution de IN #163

Closed
maieul wants to merge 5 commits from issue_44 into master
maieul commented 10 months ago
Owner

Cette PR est plus ou moins liée à #44, sur le sens de IN dans afficher_si, même si elle ne traite pas TOUT les problèmes de #44.

Pour faire court : il se trouve que, par erreur, le JS d'afficher si implémente le IN en monoévalué, mais pas le PHP d'afficher_si, d'où un comportement incohérent.

Avec ce commit, on permet vraiment le IN en monoévalué. J'ai relu les discussions de #44. On a pas vraiment trouvé de solution optimale, alors du coup je dirais que TANT PIS, on garde ce IN qui a un sens d'INTERSECTION en cas de valeur multiévaluée. Et, à ma connaissance, personne pour l'instant n'a eu besoin d'avoir un test qui serait "verifier que l'ensemble des réponses est inclus dans l'ensemble à droite", donc on s'en fiche un peu...

Cette PR est plus ou moins liée à #44, sur le sens de `IN` dans afficher_si, même si elle ne traite pas TOUT les problèmes de #44. Pour faire court : il se trouve que, par erreur, le JS d'afficher si implémente le `IN` en monoévalué, mais pas le PHP d'afficher_si, d'où un comportement incohérent. Avec ce commit, on permet **vraiment** le IN en monoévalué. J'ai relu les discussions de #44. On a pas vraiment trouvé de solution optimale, alors du coup je dirais que TANT PIS, on garde ce IN qui a un sens d'INTERSECTION en cas de valeur multiévaluée. Et, à ma connaissance, personne pour l'instant n'a eu besoin d'avoir un test qui serait "verifier que l'ensemble des réponses est inclus dans l'ensemble à droite", donc on s'en fiche un peu...
maieul added 1 commit 10 months ago
57ac077ad2 Afficher_si,
maieul changed title from [WIP] to [WIP] Légère evolution de IN 10 months ago
maieul added 4 commits 10 months ago

Donc si je comprends bien, avec le même opérateur IN, apès ça, si à gauche c'est un champ unique, ça fait un in_array de la liste à droite, et si à gauche c'est un champ multiple (cases par ex), ça fait un intersect ?

Moi ça me va, ça reste le plus simple à comprendre.

(tiens pourquoi la branche est déjà désynchro alors que c'est une nouvelle PR ?)

Donc si je comprends bien, avec le même opérateur IN, apès ça, si à gauche c'est un champ unique, ça fait un in_array de la liste à droite, et si à gauche c'est un champ multiple (cases par ex), ça fait un intersect ? Moi ça me va, ça reste le plus simple à comprendre. (tiens pourquoi la branche est déjà désynchro alors que c'est une nouvelle PR ?)
Collaborator

Puisque je m'étais exprimé je dirais que oui j'ai l'impression que le fait que IN puisse être "monovalué à gauche" aide à comprendre son fonctionnement "intersect" en mode "multivalué à gauche".
Et bravo de pas avoir lâché le morceau !

Puisque je m'étais exprimé je dirais que oui j'ai l'impression que le fait que IN puisse être "monovalué à gauche" aide à comprendre son fonctionnement "intersect" en mode "multivalué à gauche". Et bravo de pas avoir lâché le morceau !
Poster
Owner

Donc si je comprends bien, avec le même opérateur IN, apès ça, si à gauche c'est un champ unique, ça fait un in_array de la liste à droite, et si à gauche c'est un champ multiple (cases par ex), ça fait un intersect ?

c'est ca (même si j'ai implémenté autrement, en transformant le monoevalué en tableau

Puisque je m'étais exprimé je dirais que oui j'ai l'impression que le fait que IN puisse être "monovalué à gauche" aide à comprendre son fonctionnement "intersect" en mode "multivalué à gauche".
Et bravo de pas avoir lâché le morceau !

et donc on cloturerait #44 (pour être sur de bien avoir compris vos réponses) ?

(tiens pourquoi la branche est déjà désynchro alors que c'est une nouvelle PR ?)

parce que entre temps j'ai mis sur master le fix concernant le date

> Donc si je comprends bien, avec le même opérateur IN, apès ça, si à gauche c'est un champ unique, ça fait un in_array de la liste à droite, et si à gauche c'est un champ multiple (cases par ex), ça fait un intersect ? c'est ca (même si j'ai implémenté autrement, en transformant le monoevalué en tableau > Puisque je m'étais exprimé je dirais que oui j'ai l'impression que le fait que IN puisse être "monovalué à gauche" aide à comprendre son fonctionnement "intersect" en mode "multivalué à gauche". Et bravo de pas avoir lâché le morceau ! et donc on cloturerait #44 (pour être sur de bien avoir compris vos réponses) ? > (tiens pourquoi la branche est déjà désynchro alors que c'est une nouvelle PR ?) parce que entre temps j'ai mis sur master le fix concernant le date
maieul closed this pull request 10 months ago
maieul referenced this issue from a commit 10 months ago
maieul referenced this issue from a commit 10 months ago
Poster
Owner

C'est donc intégré. Et je considère qu'on cloture ainsi #44. Je documenterai après release.

C'est donc intégré. Et je considère qu'on cloture ainsi #44. Je documenterai après release.
This pull request cannot be reopened because the branch was deleted.
Sign in to join this conversation.
No reviewers
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This pull request currently doesn't have any dependencies.

Loading…
There is no content yet.