fragilité du dictionnaire passé en attribut

[lnalborczyk]

Comme je disais ailleurs, le schéma actuel consiste à créer un dictionnaire par variable dans dictionary et de les mettre dans une grosse liste qu'on récupère dans encrypt. A la sortie de encrypt, cette liste-dictionnaire est attachée en attribut à la dataframe encryptée, pour pouvoir être utilisée par decrypt.

C'est pas idéal car l'attribut-dictionnaire sera perdu dès que l'utilisateur modifiera la dataframe encryptée... Il faut donc trouver une meilleure idée pour que le dictionnaire soit utilisable par decrypt, mais ne soit pas visible de l'utilisateur.

[lnalborczyk]

C'est plus ou moins résolu par le commit ba287ca. Dans encrypt, j'assigne .dic au parent.frame, i.e., l'environnement d'où est appelé la fonction.

Ce n'est toujours pas idéal car:

1) généralement c'est l'environnement global, et c'est généralement pas conseillé des trucs à l'environnement global à partir d'une fonction dan un package right ?

2) si (je ne sais pour quelle raison) l'utilisateur change d'environnement entre son utilisation de encrypt et decrypt, on est *****

[cedricbatailler]

Je serai plus pour que le dictionnaire soit défini explicitement par l'utilisateur. Je ne me souvient plus de pourquoi tu voulais changer.

Je m'étais pas rendu compte qu'il y avait ces modifications là dans la PR #15. Il faudrait être plus explicite sur le contenu des PR, les regrouper par fonctionnalités ajoutées.

Ce qui me paraîtrait le plus cohérent à l'heure actuelle c'est de basculer sur le fonctionnement précédent : 1) définition explicite du dictionnaire, 2) cryptage du DF, 3) décryptage. Il y a plein de cas de figure où définir quelque chose dans l'environnement me parait être une mauvaise idée, genre si tu veux transmettre le dico à quelqu'un après qu'il ait fait le traitement sur des données cryptées.

Je vois pas ce qu'on gagne à ne pas être explicite dans la définition du dico.

[lnalborczyk]

Et bien je pense que c'est souhaitable que le dictionnaire ne soit pas visible par l'utilisateur qui est sensé y être aveugle non ? Au pire (au mieux), on peut ajouter un argument "visible_dic" (TRUE/FALSE) à encrypt qui permette à l'utilisateur d'obtenir le dictionnaire s'il le souhaite mais je pense que c'est souhaitable que par défaut il ne soit pas visible...si on a le code sous les yeux, le code n'est plus vraiment un code, right ?

Et pour l'utilisateur c'est plus ergonomique, t'as juste à utiliser encrypt, tu n'as pas à te soucier de comment c'est encrypté et à le faire toi même...

[cedricbatailler]

Le gain d'ergonomie est négligeable par rapport à ce que ça implique dans l'environnement de l'utilisateur. Vraiment je pense que c'est une meilleure idée que les fonctions de base soient le plus explicite possible sur ce qu'elles font. Et créer une fonction qui à la fois modifie un jeu de donnée et l'environnement me parait être une mauvaise idée (e.g., l'utilisateur appelle la fonction sans assigner le jeu de donnée encrypté et au final on a quand même un truc créé dans l'environnement). Très honnêtement il me faudra des arguments bétons pour me faire changer d'avis sur ce point ! :smile:

En ce qui concerne la visibilité du dictionnaire, je reconnais que c'est un point à considérer mais un utilisateur qui s'engage dans la démarche de masquer ces variables ne va vraisemblablement pas regarder ce dictionnaire. En revanche on peut considérer que même si le dictionnaire prend la forme d'un data.frame, on puisse envisager des méthodes qui masquent le contenu des colonnes lorsque celui-ci est appelé.

[lnalborczyk]

C'est toi le chef donc à toi de prendre la décision, mais ça me parait très contre-intuitif de devoir encrypter soi-même le jeu de données en deux étapes: 1) créer le code puis 2) encrypter la df (essayes de t'imaginer utiliser le package dans ta pratique courante).

Et oui j'entends bien l'argument (fallacieux) de "celui qui prend l'initiative de crypter ses données ne va surement pas aller regarder le code", mais pourquoi lui en laisser l'opportunité ?

Cela dit, si tu veux revenir à ce fonctionnement là, cela ne nécessite que d'infimes changements, et ne remet pas en cause la plupart des modifications de mes derniers commits (qui concernent en majorité l'implémentation de la capture de variables multiples) :)

En revanche on peut considérer que même si le dictionnaire prend la forme d'un data.frame, on puisse envisager des méthodes qui masquent le contenu des colonnes lorsque celui-ci est appelé.

Et bien oui, c'est ça qu'il faudrait implémenter ! Ca existe ?