@AugierLe42e ouais j'ai toujours trouvé qu'il manquait une option genre une directive #TktFrere pour dire au compilo de te laisser accéder aux trups privés
@AugierLe42e j'ai d'ailleurs toujours pas compris comment on était censé faire pour tester des classes pour vérifier les valeurs de ses attributs privés, à part en faisant une copie de la classe avec l'attribut qu'on veut vérifier en public (stub spy mock je sais même pas c'est quoi le terme) et si on met l'attribut en public de base on se fait reprendre par nos profs que ça serait horrible d'un point de vue sécurité :c
@AugierLe42e mettre un attribut en privé mais mettre un getter et un setter qui ne fait aucun check et dire que c'est une bonne pratique de code on se demande si eux même ils y croient 🫠
@AugierLe42e Le principe c'est que si c'est privé/protected t'es pas censé y avoir accès autrement que par les points d'accès données. Alors en tant qu'utilisateur de bibliothèques parfois c'est frustrant mais en tant que développeur de bibliothèque ou de projet commun a d'autre dev tu ne veux pas que les gens viennent trifouiller dans les trucs tel qu'ils sont prévu car ils estiment que ce serait plus simple/résoudrait des trucs de passer par là alors que pas du tout pour l'implémentation
@AugierLe42e
C'est pas une question d'adulte et de petite roulette.
En faisant tes modifs hijack c'est très bien, ça marche cool. L'implémentation interne change tu refais tout? ton code est à reprendre, etc
En terme de maintenabilité c'est se créer plus de problème que de solution que d'aller bricoler avec ce qui ne doit pas être visible pour toi.
Quand tu bosses avec plusieurs dizaines de personnes t'as pas envie de ça
Tu run les tests de la lib quand tu fais tes "modifs" hijack dedans?
@AugierLe42e oui si l'api publique change c'est obliqué mais en privé tu peux changer un million de truc sans que ça change rien pour l'utilisateur de l'api publique qui n'a rien changé. Hors toi ton code tu dois le changer dès qu'ils font des changements car t'as contourner un truc.
@AugierLe42e ouais et on fait plein de cobol encore partout et donc?
Le fait qu'ils utilisent python ne veut pas dire qu'ils font n'importe quoi avec la portée des variable, qu'il bricole les libs dont elles ont fourni une API publique parce qu'elle le peuvent.
C'est pas parce qu'un truc est possible dans un langage et que ça se passe vaguement bien car les gens font gaffe que c'est une si bonne idée. Sinon on peut parler des très bonne idée de javascript et dire qu'on devrait faire ça partout
@AugierLe42e tu dis que python parce que c'est utilisé sur de gros projet ça permet de justifier que c'est une bonne idée.
Cas concret, ton code hijack tu l'a fait aujourd'hui. Tu reprends ce projet dans 2 ans, met a jour les libs. Tu as contourné un truc, ton code a l'air de toujours marché plutôt bien mais ça a un impact ailleurs. Il va te falloir combien de temps pour retrouver que c'est parce que t'as contourner l'api publique que ça merde ailleurs?
@AugierLe42e oui mais ce bug il n'était pas censé être là et n'aurait pas dû être là car tu n'a rien changer dans ton code l'api publique n'a pas changer.
@Schoumi @AugierLe42e dans le même genre que la visibilité c'est le typage multiple. Python permet qu'une variable soit un coup un entier, un coup une chaine de caractère. Ce n'est pas parce c'est possible qu'il faut l'utiliser. En tout cas de mon point de vue ça ne peut être qu'une mauvaise idée.
Quand je developpais (ya longtemps) on pouvait faire de la reflection pour acceder aux méthodes privées mais quand tu le faisais, tu savais que ce n'est pas bien.
Il y a des cas où il n'y a pas de vraie raison de restreindre l'accès d'un truc et où passer en privé est juste un mauvais choix de design, et ce serait bien mieux si tu pouvais aller monkey-patcher tout en Java comme tu le fais en Python.
Mais il y a aussi des cas où un truc ne devrait juste pas être accessible parce que ça n'apporterait rien mais que si t'y touches ça casse tout, et dans ce cas c'est Python auquel il manque un vrai mécanisme de visibilité (même si y a parfois moyen de contourner, mais bon, 'faut forcer).
Le souci avec la visibilité en Java, c'est surtout que le truc pousse pour l'utiliser sans réfléchir aux besoins réels.
@AugierLe42e après je suis convaincu qu'il faut accepter les règles du jeu du langage sur lequel on travaille et ne pas transposer ce qu'on apprécie d'un autre langage qu'on ne peut pas utiliser. il y a aussi la sensibilité de chacun, l'école.
je préfère le typage dur, définir la portée des variables et utiliser les méthodes de librairie que le développeur a prévu qu'on utilise.
ceci dit je comprends la frustration que ça représente de ne pas pouvoir le faire.
D'une part, le __ en début de nom est loin d'être une façon de rendre quelque chose privé, dans la mesure où justement, ça auto-documente le truc et donc te donne la possibilité d'aller le chercher facilement. À la limite, le _ seul fait un peu plus ce taff (et rend cette convention de nommage débile, mais passons).
D'autre part, la question n'est pas d'être un adulte qui sait ce qu'il fait ou pas, la question est d'identifier ce qui relève de la mécanique interne sensible pour pouvoir la protéger convenablement. C'est la même chose que pour les objets physiques : si un disque dur mécanique n'a pas sa tête de lecture à l'air libre, ce n'est pas parce que le fabriquant considère que t'es pas un adulte, c'est parce que si de la poussière se dépose dessus ça va moins bien marcher.
Une « API privée », c'est simplement contradictoire, hein. Soit le truc relève de la mécanique interne et doit être privé, soit tu mets en place une interface pour y accéder, les deux sont par définition mutuellement exclusifs. C'est une question de conception.
- replies
- 0
- announces
- 0
- likes
- 0
Mais ce que je dis, c'est qu'il manque à Python (ou alors je ne l'ai pas encore trouvé) un mécanisme qui permet d'avoir un truc qui relève du fonctionnement interne de l'objet, et donc auquel l'extérieur n'a pas accès directement (déclencher une exception quand tu tentes d'y accéder depuis ailleurs serait une bonne façon de faire ça).
(Voire, qu'est-ce qu'un set apporte par rapport à une list où tu demandes explicitement aux gens qui vont s'en servir de faire bien gaffe au moment d'insérer des données qu'elles ne soient pas déjà dedans ?)
C'est généralement techniquement possible de coder en ne mettant aucune restriction et en croisant les doigts pour que les gens qui s'en serviront ne viennent pas faire de conneries avec, donc strictement parlant, on peut tout à fait argumenter que ça n'apporte rien d'en placer, des restrictions. Mais c'est quand même bien quand l'outil est capable de veiller à sa propre intégrité et où ce qui risque de te pêter à la tronche est protégé comme il faut.
Le point qui est gênant avec la visibilité privée n'est pas sa présence, mais le fait qu'elle soit utilisée abusivement, dans des cas où tu peux avoir un intérêt à y accéder depuis l'extérieur. C'est un problème de conception, pas un problème avec la fonctionnalité elle-même.
Perso quand je bosse sur des trucs, j'essaye de les concevoir d'une façon qui les rend aussi extensibles que possible de base, pour que tu puisses intervenir dessus sans avoir besoin de monkey-patcher, mais il reste toujours quelques attributs que j'essaye de protéger parce que si t'y touches, tout pète.
On est en tout cas d'accord sur le fait que l'usage majoritaire en Java utilise la visibilité d'une façon qui a l'air d'être plus automatique que réfléchie et donc pose facilement problème.
@AugierLe42e j'ai le sentiment que dans tous les cas, tu ne seras pas convaincu. j'aurais tendance à conclure en disant que ce langage ne te convient pas ;-)
Voilà. Les modificateurs d'accès, c'est de droite 👀
