[spip-dev] Fonction table_valeur() et les valeurs null

Dev
1

Hello,

Dans le plugin Rainette, je distingue les données non fournies par le service météo des données indisponibles pour un certain laps de temps.

Pour ce faire, j’initialise le tableau associatif à null et je remplis les données configurées comme fournies par le service. De fait, les données non fournies reste à null et quand je les affiche avec leur unité en appelant la fonction rainette_afficher_unite() je repère le null et n’affiche rien. Par contre, quand je repère la chaine vide (indisponible) j’affiche N/D pour dire que c’est temporairement indisponible.

Tout cela est bien beau mais j’ai un souci avec table_valeur() dans certains modèles car je fais des affichages du type :

[


  • <:rainette:precipitation|ucfirst:>

    (#VALEUR{heure/#GET{index_heure}/precipitation}|rainette_afficher_unite{precipitation, -1, #ENV{extras/service}})

    • #SET{pluie, oui}]

    C’est un cas où l’index [heure][0][precipitation] stocke la valeur null.
    Or dans la fonction table_valeur() le code suivant est déroulé, sachant que la variable $defaut est égale à la chaine vide :

    } elseif (is_array($table)) {
    $table = isset($table[$k]) ? $table[$k] : $defaut;
    }

    Mais comme la fonction isset() identifie si une variable est définie ET est différent de null le résultat fait que $table prend la valeur chaine vide de défaut et écrase donc ma valeur null.
    J’affiche donc N/D et non rien comme prévu dans le modèle.

    Ce comportement de table_valeur() est-il voulu ?
    Si non, il faudrait distinguer le fait que la variable n’est pas définie et la variable est null ce qui résoudrait mon problème.
    Si oui, je ne vois pas comment m’en sortir simplement sachant que je ne peux pas connaitre le défaut lors de la compilation du modèle sans entrer dans une usine à gaz.

    Vos avis ?

    2

    En PHP on considère généralement NULL comme étant non défini. D'où le isset(). À mon avis il ne faut pas revenir là dessus.

    Tu peux aussi te faire ton propre filtre avec un array_key_exists à la place peut être ? Ou on pourrait ajouter un argument en plus à table_valeur pour indiquer quoi faire avec les NULL (utiliser isset ou array_key_exists). ($keep_null ou $conserver_null = false), en conservant false par défaut.

    MM.

    3

    Yop,

    4

    Yop,

        En PHP on considère généralement NULL comme étant non défini. D'où
        le isset(). À mon avis il ne faut pas revenir là dessus.

    Ben a ce propos je suis plus mitigé.

    Notre écriture est strictement équivalente au nouvel opérateur PHP7 '??' :
    $table = $table[$k] ?? $defaut;

    «The expression (expr1) ?? (expr2) evaluates to expr2 if expr1 is NULL, and expr1 otherwise.

    In particular, this operator does not emit a notice if the left-hand side value does not exist, just like isset(). This is especially useful on array keys. »

    Oui l'option supplémentaire pourrait être intéressante mais je me
    demande si il ne faudrait pas inverser le défaut, à savoir que le
    conserver_null soit actif par défaut.
    Est-ce que ça foutrait vraiment le bazar ?

    Bah, c'est juste que ça change justement le comportement par rapport à avant. Si on applique cela par défaut, là où on retournait la valeur $defaut si la valeur testée valait NULL, on retournerait NULL.

    Ça m'étonnerait pas que ça puisse perturber des utilisations en place. J'en suis pas certain non plus, c'est juste que c'est possible.

    MM.

    5

    Yop,