> 2) Le choix du C c'est pas pour faire warlordz, c'est parce qu'on peut plus facilement faire des bindings faire d'autres langages.
C'est exactement ce que je dis à propos de sa vision à court terme et de l'absence de reflexion prolongée. Le choix du C pour travailler avec dans un contexte objet avec la gestion de l'héritage est complètement débile et rien que les critères de qualité du code aurait du suffire à exclure ce choix.
L'argument binding prix sous l'angle objet est également débile. On choisit un langage non objet pour manipuler des objets qui seront bindés dans un langage objet ?
Mais pour l'argument binding, l'argument à retenir tout de même, c'est que la qualité d'un binding ne dépend pas de la facilité à écrire le binding mais de la facilité à le faire évoluer. Or ici, le C est très largement perdant. Certe, il est facile d'écrire des correspondances pour une struct C, mais d'une part il faut le faire à la main pour toutes les struct existantes et donc ça prend beaucoup de temps, d'autre part c'est un processus très manuel qu'il faut recommencer complètement à chaque nouvelle version. Sans compter des problèmatiques de possession des objets gérés pas évident à mettre en oeuvre dans des langages de script: qui détruit l'objet, le script ou la lib orignielle ? Comment je fais passer l'info au script qu'un objet a été détruit, ou bien comment je signale a la lib que le script ne veut pas que l'objet X soit détruit parce qu'il en a besoin. Ces problématiques complexes sont d'autant plus difficile à resoudre si on doit le faire manuellement pour chaque objet dont on s'occupe.
Tout ça fait que les bindings Gnome ont oscillé entre un peu en retard et complètement à la rue. En général, un mec a contribué beaucoup de temps à un moment donné mais a abandonné au bout de 6 mois. La majorité des bindings ne concernaient qu'une seule version de Gtk et une très petite partie de Gnome. Aucun des bindings ne profitait de ce qui était fait par les autres.
Du côté de KDE, le besoin en binding s'est tout d'abord beaucoup moins fait sentir puisque le langage de base, le C++, est beaucoup plus évolué et permettait plus de choses. Ensuite, les en-têtes des fichiers C++ contiennent beaucoup d'information et sont relativement facile à traiter de façon automatique. Les bindings KDE et Qt sont générés contrairement aux anciens bindings Gtk et Gnome qui étaient écrits. Les mecs qui bossent sur les bindings ne bossent que sur le moteur de génération et de gestion dynamique, pas sur la partie débile qui consiste à ré-écrire la classe X dans le langage Y.
Aujourd'hui les bindings Gnome et KDE sont générés automatiquement et sont gérés par un moteur partagé entre tous les bindings. Le langage d'origine a finalement très peu d'influence sur le résultat.
Donc encore une fois, MDI a privilégié la vision à court terme et l'absence de reflexion technique.
Quant à l'aspect warlordz, j'ai vu un certain nombre de programmeurs Gnome me dirent que ils ne feraient jamais de C++ et que du C et que c'est pour ça qu'ils aimaient bien Gnome. En ce qui me concerne, je trouve que le C orienté objet avec de l'héritage mutiple et des methodes virtuelles n'a rien à a voir avec du C pur et que c'est du foutage de gueule que de défendre gnome par le C.
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 1.
C'est exactement ce que je dis à propos de sa vision à court terme et de l'absence de reflexion prolongée. Le choix du C pour travailler avec dans un contexte objet avec la gestion de l'héritage est complètement débile et rien que les critères de qualité du code aurait du suffire à exclure ce choix.
L'argument binding prix sous l'angle objet est également débile. On choisit un langage non objet pour manipuler des objets qui seront bindés dans un langage objet ?
Mais pour l'argument binding, l'argument à retenir tout de même, c'est que la qualité d'un binding ne dépend pas de la facilité à écrire le binding mais de la facilité à le faire évoluer. Or ici, le C est très largement perdant. Certe, il est facile d'écrire des correspondances pour une struct C, mais d'une part il faut le faire à la main pour toutes les struct existantes et donc ça prend beaucoup de temps, d'autre part c'est un processus très manuel qu'il faut recommencer complètement à chaque nouvelle version. Sans compter des problèmatiques de possession des objets gérés pas évident à mettre en oeuvre dans des langages de script: qui détruit l'objet, le script ou la lib orignielle ? Comment je fais passer l'info au script qu'un objet a été détruit, ou bien comment je signale a la lib que le script ne veut pas que l'objet X soit détruit parce qu'il en a besoin. Ces problématiques complexes sont d'autant plus difficile à resoudre si on doit le faire manuellement pour chaque objet dont on s'occupe.
Tout ça fait que les bindings Gnome ont oscillé entre un peu en retard et complètement à la rue. En général, un mec a contribué beaucoup de temps à un moment donné mais a abandonné au bout de 6 mois. La majorité des bindings ne concernaient qu'une seule version de Gtk et une très petite partie de Gnome. Aucun des bindings ne profitait de ce qui était fait par les autres.
Du côté de KDE, le besoin en binding s'est tout d'abord beaucoup moins fait sentir puisque le langage de base, le C++, est beaucoup plus évolué et permettait plus de choses. Ensuite, les en-têtes des fichiers C++ contiennent beaucoup d'information et sont relativement facile à traiter de façon automatique. Les bindings KDE et Qt sont générés contrairement aux anciens bindings Gtk et Gnome qui étaient écrits. Les mecs qui bossent sur les bindings ne bossent que sur le moteur de génération et de gestion dynamique, pas sur la partie débile qui consiste à ré-écrire la classe X dans le langage Y.
Aujourd'hui les bindings Gnome et KDE sont générés automatiquement et sont gérés par un moteur partagé entre tous les bindings. Le langage d'origine a finalement très peu d'influence sur le résultat.
Donc encore une fois, MDI a privilégié la vision à court terme et l'absence de reflexion technique.
Quant à l'aspect warlordz, j'ai vu un certain nombre de programmeurs Gnome me dirent que ils ne feraient jamais de C++ et que du C et que c'est pour ça qu'ils aimaient bien Gnome. En ce qui me concerne, je trouve que le C orienté objet avec de l'héritage mutiple et des methodes virtuelles n'a rien à a voir avec du C pur et que c'est du foutage de gueule que de défendre gnome par le C.