Posté par totof2000 .
Évalué à 4.
Dernière modification le 11 mars 2023 à 16:24.
L'auteur semble dire que le fait que Rust ne soit pas un langage objet l'empêche d'implémenter correctement un GUI. Mais je trouve que ce n'est pas justifié.
Tk n'est pas implémenté en POO il me semble. X11 et les premières bibliothèques graphiques ne l'étaient pas non plus. Il y a quelques années, la programmation graphique sous Windows se faisait en C et pas en C++ et il me semble que pendant longtemps, GTK était écrite en C (je ne sais pas si c'est toujours le cas). EFL, qui sert de base à Enlightenment, est majoritairement écrit en C. Donc on peut facilement se passer de langages objet pour écrire une IHM graphique.
Je suis cepandant certain qu'écrire une IHM graphique avec Rust est plus difficile qu'avec d'autres langages, mais je ne pense pas que c'est du à autre chose.
J'ai plutôt eu l'impression qu'on parle de POO parce-que c'est tendance (et que c'est une façon de faire que connait l'auteur) d'une part et pour mettre en garde contre les conceptions habituelles (ou plutôt actuelles) qui correspondent à une façon de penser pas toujours compatible avec ce type de langage d'autre part.
Attention qu'un langage dit POO n'est pas une obligation pour mettre en œuvre certains concepts (composition, héritage, polymorphisme, etc.) Il y a déjà eu des mises en œuvre objet en pur procédural.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Oups .. j'ai ecrit le contraire de ce que je pensais :
Je suis cepandant certain qu'écrire une IHM graphique avec Rust est plus difficile qu'avec d'autres langages, mais je pense que c'est du à autre chose.
Outre ce détail, je suis d'accord, pas besoin de POO pour faire de l'IHM. Mais comme meilleur exemple, je donnerai les "Immediate GUI" qui sont par nature procédurale:
Il y a ensuite les approches fonctionnelles (dont parle un peu cet article), ou le rendu graphique est une fonction de l'état (state) de l'application:
# J'ai l'impression que l'article mélange un peu tout ....
Posté par totof2000 . Évalué à 4. Dernière modification le 11 mars 2023 à 16:24.
L'auteur semble dire que le fait que Rust ne soit pas un langage objet l'empêche d'implémenter correctement un GUI. Mais je trouve que ce n'est pas justifié.
Tk n'est pas implémenté en POO il me semble. X11 et les premières bibliothèques graphiques ne l'étaient pas non plus. Il y a quelques années, la programmation graphique sous Windows se faisait en C et pas en C++ et il me semble que pendant longtemps, GTK était écrite en C (je ne sais pas si c'est toujours le cas). EFL, qui sert de base à Enlightenment, est majoritairement écrit en C. Donc on peut facilement se passer de langages objet pour écrire une IHM graphique.
Je suis cepandant certain qu'écrire une IHM graphique avec Rust est plus difficile qu'avec d'autres langages, mais je ne pense pas que c'est du à autre chose.
[^] # Re: J'ai l'impression que l'article mélange un peu tout ....
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
J'ai plutôt eu l'impression qu'on parle de POO parce-que c'est tendance (et que c'est une façon de faire que connait l'auteur) d'une part et pour mettre en garde contre les conceptions habituelles (ou plutôt actuelles) qui correspondent à une façon de penser pas toujours compatible avec ce type de langage d'autre part.
Attention qu'un langage dit POO n'est pas une obligation pour mettre en œuvre certains concepts (composition, héritage, polymorphisme, etc.) Il y a déjà eu des mises en œuvre objet en pur procédural.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: J'ai l'impression que l'article mélange un peu tout ....
Posté par totof2000 . Évalué à 3.
Oups .. j'ai ecrit le contraire de ce que je pensais :
Je suis cepandant certain qu'écrire une IHM graphique avec Rust est plus difficile qu'avec d'autres langages, mais je pense que c'est du à autre chose.
[^] # Re: J'ai l'impression que l'article mélange un peu tout ....
Posté par David Delassus (site web personnel) . Évalué à 4.
Il faut différencier "Programmation Orientée Objet" et "Langage Orienté Objet".
Dans le premier, on a des techniques d'encapsulation, de polymorphisme (ou autrement dit: static/dynamic dispatch), etc…
Dans le second, on a un langage qui fournit des outils pour faire cela.
On peut faire de l'orienté objet en C -> http://www.cs.rit.edu/~ats/books/ooc.pdf
Preuve à l'appui, j'ai fait cette monstruosité : https://github.com/linkdd/ooduck
GTK (basé sur GObject), c'est de la POO.
Outre ce détail, je suis d'accord, pas besoin de POO pour faire de l'IHM. Mais comme meilleur exemple, je donnerai les "Immediate GUI" qui sont par nature procédurale:
Il y a ensuite les approches fonctionnelles (dont parle un peu cet article), ou le rendu graphique est une fonction de l'état (state) de l'application:
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.