Sens de IN #44

Closed
opened 2 years ago by maieul · 12 comments
maieul commented 2 years ago
Owner

Pour comprendre ce ticket, on peut se réferer :

Le problème

La saisie IN a été prévue pour permettre de tester qu'au moins une valeur d'une saisie multivaluée (à gauche de l'opérande) se trouve parmis les valeurs listées à droite de l'opérande.

Cela pose toutefois un double problème :

  1. d'une part en MYSQL/PHP, le IN n'a pas ce sens là. Elle ne peut s'appliquer qu'aux variables monovalués (à gauche de l'opérande) envers des valeurs multiples (à droite de l'operant) id_article IN 1,2,3 / in_array($valeur, $array). En fait IN se comporte plutôt comme un INTER
  2. des gens peuvent être tentés de l'utiliser pour une valeur monovalué à gauche de l'opérande (@champ@ IN "2,3" équivalent à @champ@ == 2 || @champ@ == 3).

Du coup ca pose de la confusion.

Pistes à rejeter

Concernant le point 1, on ne peut pas changer le comportement de IN pour qu'il ne se comporte plus comme un INTER, car on va casser des sites.

COncernant le point 2, on pourrait faire évoluer IN pour le permettre sur les champs monovalués, mais ca veut dire maintenir cet opérateur confusionnant

Proposition

Du coup je serai d'avis d'opter plutot pour la solution suivante :

  • ajouter un INTER pour les champs multi valués, se comportant comme le IN actuel
  • deprecier le IN actuel
  • ajouter un opérateur CHOIX / PARMIS / DANS / INCLUS DANS (en tout cas un terme francais, car le bon terme anglais serait ... IN) qui se comporte ainsi :
    • pour un champ multivalué, vérifie que TOUTE les valeurs choisies sont parmis les valeurs à droite de l'opérateur
    • pour un champ monovalué, vérifie que la valeur se trouve parmis les valeurs à droite de l'opérateur

On ajouterait une fonction de migration de IN vers INTER qui pourrait être appelé par les plugins utilisant des constructeurs de formulaire (champs extra, formidable, et d'autres)

Avis bienvenu.

Pour comprendre ce ticket, on peut se réferer : - aux remarques de JLuc ici https://contrib.spip.net/ecrire/?exec=article&id_article=5080#forum501431 - aux problèmes de @rastapopoulos ici #23 ## Le problème La saisie IN a été prévue pour permettre de tester qu'au moins une valeur d'une saisie multivaluée (à gauche de l'opérande) se trouve parmis les valeurs listées à droite de l'opérande. Cela pose toutefois un double problème : 1. d'une part en MYSQL/PHP, le IN n'a pas ce sens là. Elle ne peut s'appliquer qu'aux variables monovalués (à gauche de l'opérande) envers des valeurs multiples (à droite de l'operant) `id_article IN 1,2,3` / `in_array($valeur, $array)`. En fait IN se comporte plutôt comme un INTER 2. des gens peuvent être tentés de l'utiliser pour une valeur monovalué à gauche de l'opérande (`@champ@ IN "2,3"` équivalent à `@champ@ == 2 || @champ@ == 3`). Du coup ca pose de la confusion. ## Pistes à rejeter Concernant le point 1, on ne peut pas changer le comportement de IN pour qu'il ne se comporte plus comme un INTER, car on va casser des sites. COncernant le point 2, on pourrait faire évoluer IN pour le permettre sur les champs monovalués, mais ca veut dire maintenir cet opérateur confusionnant ### Proposition Du coup je serai d'avis d'opter plutot pour la solution suivante : - ajouter un INTER pour les champs multi valués, se comportant comme le IN actuel - deprecier le IN actuel - ajouter un opérateur CHOIX / PARMIS / DANS / INCLUS DANS (en tout cas un terme francais, car le bon terme anglais serait ... IN) qui se comporte ainsi : - pour un champ multivalué, vérifie que TOUTE les valeurs choisies sont parmis les valeurs à droite de l'opérateur - pour un champ monovalué, vérifie que la valeur se trouve parmis les valeurs à droite de l'opérateur On ajouterait une fonction de migration de IN vers INTER qui pourrait être appelé par les plugins utilisant des constructeurs de formulaire (champs extra, formidable, et d'autres) Avis bienvenu.
Poster
Owner

Complément : pour les champs multivalué == est actuellement un alias de IN. J'avoue que je ne sais pas quoi faire de ce comportement qui est franchement pas clair et logique. Fort heureusement, il n'est pas documenté. Je propose de le laisser sous le tapis (mais de mettre dans le code un commentaire disant qu'il ne faut pas le documenter).

Pour la négation !INTER aurait le sens du !IN actuel, à savoir vérifier qu'aucune valeur du champ ne se trouve parmis les valeurs à droite de l'opérande.

!DANS pour un champs multivalué serait vrai si au moins une des valeurs du champ multivalué ne se trouve pas dans les valeurs de droite.

Complément : pour les champs multivalué `==` est actuellement un alias de IN. J'avoue que je ne sais pas quoi faire de ce comportement qui est franchement pas clair et logique. Fort heureusement, il n'est pas documenté. Je propose de le laisser sous le tapis (mais de mettre dans le code un commentaire disant qu'il ne faut pas le documenter). Pour la négation `!INTER` aurait le sens du `!IN` actuel, à savoir vérifier qu'aucune valeur du champ ne se trouve parmis les valeurs à droite de l'opérande. `!DANS` pour un champs multivalué serait vrai si au moins une des valeurs du champ multivalué ne se trouve pas dans les valeurs de droite.

qu'est-ce que tu appelles "comme un INTER" ? ça n'existe ni en SQL ni en PHP "inter", donc ça parait pas plus facile à comprendre il me semble (pour les gens qui ont déjà lu quelques langages, et pour les autres, encore moins alors que le mot IN est immédiablement compréhensible par tou⋅tes)

et je suis moyen pour mélanger anglais et français dans la même syntaxe

qu'est-ce que tu appelles "comme un INTER" ? ça n'existe ni en SQL ni en PHP "inter", donc ça parait pas plus facile à comprendre il me semble (pour les gens qui ont déjà lu quelques langages, et pour les autres, encore moins alors que le mot IN est immédiablement compréhensible par tou⋅tes) et je suis moyen pour mélanger anglais et français dans la même syntaxe
Poster
Owner

INTER(SECTION) de deux ensembles.

C'est bien de cela dont il s'agit lorsqu'on le IN actuel.

Si les cases cochées sont 2,3 et que on a teste @truc@ IN '3,4` ce qu'on vérifie c'est que l'intersection (2,3) et (3,4) est non nul. Alors que IN veut dire littéralement que (2,3) serait compris dans (3,4)

INTER(SECTION) de deux ensembles. C'est bien de cela dont il s'agit lorsqu'on le IN actuel. Si les cases cochées sont 2,3 et que on a teste `@truc@` IN '3,4` ce qu'on vérifie c'est que l'intersection (2,3) et (3,4) est non nul. Alors que IN veut dire littéralement que (2,3) serait compris dans (3,4)

Oui mais "inter" ne se comprend pas du tout en soit, contrairement à "in". C'est un préfixe de plein de mots différents. Dans SQL c'est "intersect" justement, pas "inter", ce qui est plus compréhensible mais plus long. En PHP pareil "array_intersect", pas "array_inter".

Oui mais "inter" ne se comprend pas du tout en soit, contrairement à "in". C'est un préfixe de plein de mots différents. Dans SQL c'est "intersect" justement, pas "inter", ce qui est plus compréhensible mais plus long. En PHP pareil "array_intersect", pas "array_inter".
Poster
Owner

Oui, du coup peut être prendre INTERSECT

mais par contre je te rejoint sur le fait que melanger anglais/francais c'est pas top

Oui, du coup peut être prendre INTERSECT mais par contre je te rejoint sur le fait que melanger anglais/francais c'est pas top
Poster
Owner

(désolé coquille c'est pas que cela -> c'est pas top voulais-je dire)

(désolé coquille c'est pas que cela -> c'est pas top voulais-je dire)
Collaborator

Oui bonne piste maieul. Moi je trouve que INTER c'est clair quand on raisonne sur des ensemble de valeurs... et plus léger que INTERSECT mais INTERSECT c'est très clair aussi sur ce que ça fait.

Pour DANS si on veut pas de français et comme vu ensemble sur IRC il y a INSIDE.

Et je suis d'accord pour la négation !INSIDE pour un champs multivalué : serait vrai si au moins une des valeurs du champ multivalué ne se trouve pas dans les valeurs de droite.

Oui bonne piste maieul. Moi je trouve que INTER c'est clair quand on raisonne sur des ensemble de valeurs... et plus léger que INTERSECT mais INTERSECT c'est très clair aussi sur ce que ça fait. Pour DANS si on veut pas de français et comme vu ensemble sur IRC il y a INSIDE. Et je suis d'accord pour la négation !INSIDE pour un champs multivalué : serait vrai si au moins une des valeurs du champ multivalué ne se trouve pas dans les valeurs de droite.
Poster
Owner

un avis @tcharlss ou @nicod_ ? (je sais que vous faites souvent des afficher_si)

un avis @tcharlss ou @nicod_ ? (je sais que vous faites souvent des afficher_si)

Ce qu'il faut bien garder à l'esprit c'est que les afficher_si ils peuvent être déclarés en PHP donc par nous, des devs, pour qui on s'en fiche presque de la syntaxe tant que c'est un peu cohérent tout de même, mais surtout, c'est accessible dans des champs d'admin pour des gens pas devs du tout, dans le constructeur (donc pour Champs Extras + Formidable). Cela dit, pour elleux… tant qu'il n'y aura pas une vraie interface, ça restera assez compliqué.

Ce qu'il faut bien garder à l'esprit c'est que les afficher_si ils peuvent être déclarés en PHP donc par nous, des devs, pour qui on s'en fiche presque de la syntaxe tant que c'est un peu cohérent tout de même, mais surtout, c'est accessible dans des champs d'admin pour des gens pas devs du tout, dans le constructeur (donc pour Champs Extras + Formidable). Cela dit, pour elleux… tant qu'il n'y aura pas une vraie interface, ça restera assez compliqué.
Poster
Owner

certes, mais du coup?

certes, mais du coup?

Pour l'intersection, il me semble que "intersect" est le mieux : c'est ce qu'utilise à la fois SQL et PHP, les deux choses que celleux qui sont devs peuvent avoir déjà lu et donc reconnu.

Pour l'autre, bah, c'est vraient con car c'est bien "in" qui serait le plus logique. @truc@ IN bidule,chouette => ce qui est dans truc doit faire partie de la liste == "in_array". D'autant que là aussi : SQL utilise "IN", et PHP "in_array" donc "IN" aussi.

Si en SQL ya "interect" et PHP "array_intersect" et que nous on utilise alors "intersect" pour cette opération logique.
Alors si SQL utilise "in" et PHP "in_array", on devrait utiliser "in" pour l'autre.

Relouuuu

Pour l'intersection, il me semble que "intersect" est le mieux : c'est ce qu'utilise à la fois SQL et PHP, les deux choses que celleux qui sont devs peuvent avoir déjà lu et donc reconnu. Pour l'autre, bah, c'est vraient con car c'est bien "in" qui serait le plus logique. @truc@ IN bidule,chouette => ce qui est dans truc doit faire partie de la liste == "in_array". D'autant que là aussi : SQL utilise "IN", et PHP "in_array" donc "IN" aussi. Si en SQL ya "interect" et PHP "array_intersect" et que nous on utilise alors "intersect" pour cette opération logique. Alors si SQL utilise "in" et PHP "in_array", on devrait utiliser "in" pour l'autre. Relouuuu
maieul referenced this issue from a commit 10 months ago
maieul referenced this issue from a commit 10 months ago
maieul closed this issue 10 months ago
maieul referenced this issue from a commit 10 months ago
Poster
Owner

#163 a été intégré en master + v3.

Pour résumer :

  • si le champ est monovalué, IN a le sens de "la valeur appartient à ce
    tableau"
  • si le champ est tabulaire, IN a le sens historique de "au moins une
    valeur appartient à ce tableau" (donc plutôt un INTERSECTION)
  • on laisse tomber de changer de syntaxe pour exprimer une vrai
    INTERSECTION + on garde la petite erreur logique sur IN qui prend le
    sens d'intersection
  • a priori, pas besoin de dev un INCLUS, et si c'est le cas on fera plus
    tard.
#163 a été intégré en master + v3. Pour résumer : - si le champ est monovalué, IN a le sens de "la valeur appartient à ce tableau" - si le champ est tabulaire, IN a le sens historique de "au moins une valeur appartient à ce tableau" (donc plutôt un INTERSECTION) - on laisse tomber de changer de syntaxe pour exprimer une vrai INTERSECTION + on garde la petite erreur logique sur IN qui prend le sens d'intersection - a priori, pas besoin de dev un INCLUS, et si c'est le cas on fera plus tard.
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.