Mouais... Est-ce que ce ne serait pas plus intelligent à long terme de porter GNUStep en C++, histoire de s'affranchir de la dépendance à un langage très très peu utilisé, et de donner la possibilité à plus de développeurs de contribuer ?
Parce que ça prends enormement de temps et que faire des wrappers un peu dans le style gtk-- est particulièrement inefficace et est une perte de temps incroyable. Je ne sais pas si tu as une idée de la taille de l'API de GNUStep mais c'est assez enorme :
Avec AppKit, on est franchement surpris d'arriver à faire une interface cohérente en aussi peu de temps et avec un peu d'habitude, on apprécie franchement l'Objective-C.
Faire porter la responsabilité aux développeurs de gcc qui-traînent-les-pieds-à-committer-le-patch, c'est pas très constructif.
Parce qu'entre appliquer un patch et reécrire GNUStep en C++ tu trouves que le deuxième est plus constructif ?
Tu as l'air de penser que GNUStep est particulièrement fermé à cause de l'Objective-C alors qu'il n'en est rien. JIGS et RIGS apportent justement cette ouverture en permettant aux programmeurs java et ruby d'utiliser les bibliothèques GNUStep. L'ouverture serait encore plus grande si ce patch était appliqué, on verrait apparaitre peut-être plus de C++ et ça faciliterait grandement les portages. Alors dans ce cas moi je trouve que se plaindre d'un patch un peu "lent" à venir est constructif.
Déjà qu'il y a Gnome et KDE en face de vous, si en plus vous imposez l'utilisation d'un langage exotique...
Bof. Je n'ai pas l'impression que GNUStep, Gnome et KDE jouent dans la même catégorie. GNUStep part d'une base totalement différente, et à mon avis, plus saine Openstep. Et pour en revenir au langage exotique, j'ai constaté que le projet était particulièrement vivant en dépit du langage et, moi même, je prends beaucoup de plaisir à programmer en Objective-C (ça ne fait que 6 mois mais je suis surpris de l'avancement de l'appli que j'essaye de faire, je signale quand même que je programme pas mal en C++ et en java en dehors de mon temps libre, ceci explique peut-être que je n'ai pas eu trop de mal à apprendre l'Objective-C). Alors laissons lui une chance ;-)
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par bleh . En réponse à la dépêche Comparatif Intel C++ 7.0 / Gcc 3.2.1. Évalué à 5.
Parce que ça prends enormement de temps et que faire des wrappers un peu dans le style gtk-- est particulièrement inefficace et est une perte de temps incroyable. Je ne sais pas si tu as une idée de la taille de l'API de GNUStep mais c'est assez enorme :
http://www.gnustep.org/resources/documentation/base/Base.html(...)
http://www.gnustep.org/resources/documentation/gui/Gui.html(...)
Avec AppKit, on est franchement surpris d'arriver à faire une interface cohérente en aussi peu de temps et avec un peu d'habitude, on apprécie franchement l'Objective-C.
Faire porter la responsabilité aux développeurs de gcc qui-traînent-les-pieds-à-committer-le-patch, c'est pas très constructif.
Parce qu'entre appliquer un patch et reécrire GNUStep en C++ tu trouves que le deuxième est plus constructif ?
Tu as l'air de penser que GNUStep est particulièrement fermé à cause de l'Objective-C alors qu'il n'en est rien. JIGS et RIGS apportent justement cette ouverture en permettant aux programmeurs java et ruby d'utiliser les bibliothèques GNUStep. L'ouverture serait encore plus grande si ce patch était appliqué, on verrait apparaitre peut-être plus de C++ et ça faciliterait grandement les portages. Alors dans ce cas moi je trouve que se plaindre d'un patch un peu "lent" à venir est constructif.
Déjà qu'il y a Gnome et KDE en face de vous, si en plus vous imposez l'utilisation d'un langage exotique...
Bof. Je n'ai pas l'impression que GNUStep, Gnome et KDE jouent dans la même catégorie. GNUStep part d'une base totalement différente, et à mon avis, plus saine Openstep. Et pour en revenir au langage exotique, j'ai constaté que le projet était particulièrement vivant en dépit du langage et, moi même, je prends beaucoup de plaisir à programmer en Objective-C (ça ne fait que 6 mois mais je suis surpris de l'avancement de l'appli que j'essaye de faire, je signale quand même que je programme pas mal en C++ et en java en dehors de mon temps libre, ceci explique peut-être que je n'ai pas eu trop de mal à apprendre l'Objective-C). Alors laissons lui une chance ;-)