J'ai même un peu de mal à croire qu'on génèrera automatiquement les bindings sans avoir besoin d'y toucher.
On verra. Le coup du binding généré automatiquement c'est un peu le cas extrême, moi non plus je suis moyen convaincu. Par exemple en ocaml, on continuera à écrire des trucs à la main, c'est sûr.
Mais ça va quand même beaucoup accélérer la création des bindings.
Euh là tu ne fais que reformuler ce que t'as déjà dis :)
c'est toujours vrai :)
un exemple : GList *gtk_truc_bidule_chose (machin *arg1, guint arg2);
est-ce que :
- arg1 peut être NULL ?
- arg1 est une simple struct passée par pointeur ?
- arg1 est un tableau de longueur arg2 ?
- arg1 est un tableau terminé par un NULL (et arg2 n'a rien à voir) ?
et :
- qu'est-ce qu'il y a dans la GList ? (des char*, des objets ?)
- comment gère-t-on la mémoire de la GList ? (il y a 3 possibilités: rien à libérer, libérer la GList, libérer la GList + tous les éléments).
Si le programmeur C peut utiliser ces en-têtes pour compiler son programme avec ces libs sans problème
justement, le programmeur C ne peut pas se baser uniquement sur les prototypes pour écrire du code correct, il a besoin de la doc. Le C n'est pas sûr mais tous les autres langages le sont. L'objectif est que le binding soit sûr et utilise les mêmes conventions que le langage (comme si la lib était écrite nativement dans le langage).
Oué enfin c'est vraiment pas la mort de relancer un script qui regénère les bindings une fois pour toute, faut pas abuser :)
plus besoin de compilateur C, de l'environnement de compilation de GTK+ (les .h), ni de celui du langage ...
[^] # Re: du déjà vu
Posté par Vivi . En réponse à la dépêche Toutes les API GNOME dans tous les langages et pour bientôt ?. Évalué à 6.
On verra. Le coup du binding généré automatiquement c'est un peu le cas extrême, moi non plus je suis moyen convaincu. Par exemple en ocaml, on continuera à écrire des trucs à la main, c'est sûr.
Mais ça va quand même beaucoup accélérer la création des bindings.
Euh là tu ne fais que reformuler ce que t'as déjà dis :)
c'est toujours vrai :)
un exemple :
GList *gtk_truc_bidule_chose (machin *arg1, guint arg2);
est-ce que :
- arg1 peut être NULL ?
- arg1 est une simple struct passée par pointeur ?
- arg1 est un tableau de longueur arg2 ?
- arg1 est un tableau terminé par un NULL (et arg2 n'a rien à voir) ?
et :
- qu'est-ce qu'il y a dans la GList ? (des char*, des objets ?)
- comment gère-t-on la mémoire de la GList ? (il y a 3 possibilités: rien à libérer, libérer la GList, libérer la GList + tous les éléments).
Si le programmeur C peut utiliser ces en-têtes pour compiler son programme avec ces libs sans problème
justement, le programmeur C ne peut pas se baser uniquement sur les prototypes pour écrire du code correct, il a besoin de la doc. Le C n'est pas sûr mais tous les autres langages le sont. L'objectif est que le binding soit sûr et utilise les mêmes conventions que le langage (comme si la lib était écrite nativement dans le langage).
Oué enfin c'est vraiment pas la mort de relancer un script qui regénère les bindings une fois pour toute, faut pas abuser :)
plus besoin de compilateur C, de l'environnement de compilation de GTK+ (les .h), ni de celui du langage ...