TImaniac a écrit 6423 commentaires

T'as tous les inconvenients de ne pas avoir un langage oriente objet et aucun des avantages du C (langage sobre et efficace).
Ah si t'as l'énorme avantage de pouvoir appeler facilement un API en C depuis n'importe quel langage, alors qu'appeler un API C++ n'est pas donné à tous les langages de haut niveau. Il faut voir aussi qu'à l'époque du choix de C par Gnome le C++ n'était pas vraiment standardisé dans les compilos (je précises dans les compilos)

C'est une idée fausse hélas très répandue sur OCaml.
Non ce n'est pas une idée fausse, c'est mon idée tirée de mon expérience.
Même si OCaml permet de programmer de plusieurs manière, je ne lui vois pas beaucoup d'intérêt si c'est pour l'utiliser de manière impérative. Je me trompes peut être mais à mon sens toute la puissance de OCaml réside dans le mixage objet/fonctionnel qui permet d'exprimer avec force ce qu'on veut faire, ce qui permet au compilo de faire tout pleins de déductions et d'optimisation. Cela dis je suis peut être complètement à côté de la plaque :)

Le langage C++ au lieu de poser des problemes, comme tu pense le penser
Il pose pas des problèmes pour récupérer les infos, le langage C++ étant par nature objet il est sans doute plus facile de récupérer certaines infos, mais je parle de la réalisation du binding en soit : en gros faut faire un wrapper C++ intermédiaire qui soit plus friendly car très peu de langage comprennent "nativement" le C++, contrairement au C avec lequel la plupart des langages sont capable d'intéragir. Je ne suis pas sûr qu'une couche intermédiaire soit un gage d'efficacité, et il faut refaire cette couche pour tous les langages... C'est en ce sens que le binding d'API C++ est "lourd" à mon sens.

tres belle demonstration, tu as deja vu des headers C++ de KDE ? :)
Ce que je voulais dire c'est que pour faire le binding "tel quel", les .h suffisent, aussi bien en c++ qu'en C. Après je viens enfin de comprendre l'intérêt de l'introspection dans certaines situation, notamment pour améliorer considérablement la sémantique du binding et rendre le tout plus friendly au langage de haut niveau. J'aurai tout de même aimé retrouver cette info dans la news, car c'est vraiment là que réside l'intérêt de l'approche à mon sens.

Mais bien sur. Et la marmotte ...
Oué je me suis planté je sais.

ouahou, va falloir que t'introduise un if pour gérer les 2 cas, effectivement c'est peut être trop compliqué en fin de compte ;)

Je me répond à moi même : dans le cas des tableaux il faut effectivement le préciser à la mano après coup. Si cette info peut être récupérée dynamiquement cela peut être utile puisque cela améliore nettement le binding (sans l'empêcher toutefois)

L'objectif est que le binding soit sûr et utilise les mêmes conventions que le langage
Justement, là on doit se baser uniquement sur les .h. Ce que tu sembles indiquer c'est qu'il y a une sémantique supplémentaire ajoutée par les dev des libs Gnome et qui ne peut être récupéré que dynamiquement. Je comprends mieux.
Cela dis je me demande si il n'y a pas des "conventions" d'utilisation qui font que ce sont les même règles qui s'appliquent partout, auquel cas il est facile d'indiquer au parser d'en-tête quelles infos supplémentaires il faut déduire dans quels cas. J'aimerai un exemple concrêt autre que gtk_truc_bidule_chose, histoire de voir comment sont gérer ces cas par les parser d'en-tête justement.

Par contre pour programmer, le profile d'une fonction ne suffit pas,
Mais comment fait le programmeur C qui utilises ces fameuses listes ? Je te demande un exemple concrêt de méthode ou classe où les en-têtes ne suffisent pas, avec ces fameuses listes si tu veux.

La partie utile de ce comportement est fournie par l'introsection sous une forme normalisée ce qui n'est pas le cas d'un simple header.
Donc le programmeur C n'a pas le choix : il fait de l'introspection en natif avec son cerveau c'est ca ?

Bah z'ont bien utilisé le compilo C# de mono, je vois pas pourquoi ils ne pouvaient pas faire de même avec le compilo VB.NET de Mono, parcque en lisant la FAQ le langage semble rentrer dans les critères "techniques", j'ai même envi de dire plus que le langage C qui n'a quasiment aucun "should have".

Bah c'est pas si bête que ca, c pas bien compliqué en Java d'ajouter une ligne dans un fichier... Et si la classe qui "valide" tiens absolument à trouver cette info pour valider, je ne vois même pas d'autre solution... Elle ne te paraît peut être pas élégante mais elle a l'avantage d'être simple et rapide à mettre en oeuvre.

Houlà oui autant pour moi :) Désolé pour la connerie monstrueuse. J'avais oublié que le (décrié) meta-compilo-qui-fait-chier était puissant :)

Enfin ca confirme ce que je pensais : bien que proposant également l'introspection, visiblement les "bindeurs" KDE n'en ont pas eu besoin pour faire de la génération automatique, les .h leurs suffisent. Je vois pas pourquoi il ne serait pas de même pour Gnome et ses .h.

Euh je vois pas en quoi ces benchs sont plus sérieux : d'abord ils ne semblent pas contredire les autres bench, et au final ce ne sont que des benchs "mathématiques", un peu comme dans les autres bench quoi.
C'est pas parcque c'est plus "sérieux" en apparence que ca a plus de valeur : ca reste un bench et ca a les mêmes limitations que les autres : à savoir que ce ne sont généralement pas des cas concrêts et quand les résultats obtenus sont du même ordre d'idée, il est bien difficile de faire une conclusion utile.

il y a trés probablement des infos qui sont rentrées "à la main".
Il y en a certaines oui, mais généralement pour rendre certaines parties plus "friendly" au programmeur, c'est pas du tout une opération indispensable. J'ai même un peu de mal à croire qu'on génèrera automatiquement les bindings sans avoir besoin d'y toucher.

le type des éléments des listes (GSList * et GLIst *), des "flags" précisant la [...]
Euh là tu ne fais que reformuler ce que t'as déjà dis :)
Je te demande de me montrer un exemple concrêt de méthode ou de je ne sais quoi qui est dans un .h, qui est destiné à être bindé, et qui ne peut l'être sans ces infos accessibles uniquement par introspection. Si le programmeur C peut utiliser ces en-têtes pour compiler son programme avec ces libs sans problème, il n'y a aucune raison qu'un autre langage ne puisse pas le faire à partir de ces seuls en-tête. J'avoue que je suis très sceptique sur la réelle utilité de cette nouvelle approche.

Tu gagne en flexibilité (pas la peine de recompiler les bindings pour chaque nouvelle version de GTK+) et tu ne perds pas beaucoup en robustesse
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 :) Par contre ce qu'on pert en robustesse... Evidemment tu me dis que le langage ne l'ai pas à la base et que donc on peut se permettre toutes les fantaisies. Là en l'occurence c'est pour "éviter" de relancer le script de génération des bindings. Hem.

oué enfin faut pas exagéré non plus, procédural et objet ne sont pas si fortement dissociés, les 2 sont complémentaires, c'est d'ailleur aussi un des succès de l'objet : sa transition avec le monde procédural est relativement "aisé" lorsqu'on compare à des méthodes beaucoup plus différentes comme la programmation déclarative.

Quelqu'un a-t-il commencé à apprendre la programmation par autre chose que du procédural impératif ?
Ben dans ma FAC ils ont (pas moi j'étais pas là au début) commencé par Scheme, pourtant on dit que l'on reste à nos premiers amours en matière de programmation, ben ils sont tous beaucoup plus productifs et heureux en codant en Java :)
La notion d'objet est facile à appréhender par le programmeur qui peut "mapper" sa vision sur le monde réel. Bref c'est relativement intuitif (même si cela ne conduit pas toujours au meilleur design). Pour l'impératif, celui-ci a l'avantage de donner un seul ordre à la fois, dans un ordre précis qui est celui dans lequel le programmeur écrit : c'est donc très simple à appréhender (même si ce n'est pas forcement intuitif) et à utiliser.
Par contre d'autres langages comme OCaml ou pire Prolog sont beaucoup plus difficile à appréhender car il demande une réflexion importante de la part du programmeur pour qu'il "ponde" le bon algo de manière conscise, sans parfois avoir la possibilité de décomposer le problème. C'est aussi ce qui fait la puissance de ces langages : il force le développeur à indiquer l'algorithme au compilateur/interprêteur qui peut alors en déduire plus d'information, conduisant parfois (souvent pour OCaml) à des optimisations qu'un compilateur plus traditionnel ne pourrait se permettre.

Mais qu'est ce que cela change que Apple construise son matos ? Le consommateur laisé s'en balance royalement ! Il n'a pas à le savoir ! Pas plus que quand il achète un PC sous Windows que ce n'est pas MS qui l'a fabriqué ! Ces détails sont des problèmes de production, de sous-traitance, etc.
On peut très bien dire que les pièces qui constituent un PC ont été conçu pour fonctionner avec Windows (ce qui est souvent le cas malheuresement), et que donc le tout forme un appareil homogène.

Alors non non non et non, on applique les mêmes règles à Apple ou à personne, on va pas faire d'exception pour eux : on peut très bien installer une distri Linux sur un MAC, ou intaller un OS Mac sur un vieux mac : comme quoi techniquement les 2 sont dissociés, et c'est tout ce qui compte pour définir la vente liée et respecter le consommateur.

Non mais oh. C'est vrai quoi :)

Ce que tu sembles oublier c'est que le langage C avait été choisi parcque justement il était facile à "binder". De plus si t'avais pris la peine de te renseigné, il existe depuis le départ des outils permettant de créer des bindings automatiquement à partir des .h. KDE n'a pas forcement la primeur en la manière.
De plus créer un binding sur KDE est très (trop) limité : le langage C++ utilisé n'est pas forcement facile à utiliser dans tous les langages de haut niveau, et très peu de langage de haut niveau implémente toutes les fonctionnalités de C++ : il en ressort des difficultés à créer le binding, voir parfois une impossibilité dans certains langage. D'où le choix pour Gnome de C qui a l'avantage d'être un dénominateur commun à tous les langages : ils sont tous capables d'utiliser le C (ou presque). Je parle même pas d'un hybride C++ qui nécessite un précompilo si tu vois ce que je veux dire.

En C++, en parsant le .h, tu as 99% de l'info dont tu as besoin.
Ben en C aussi dis donc.
Même si j'ai encore des doutes sur l'intérêt, le mécanisme mis en place dans les libs compatible "Gnome" (à la glib quoi) permettent l'introspection, ce que ne permettent absoluement pas les libs KDE.

Voilà pour ce qui était de la réplique pro-Gnome ;)

ben ça sert à générer du code correct pour le binding.
Visiblement Mono n'a pas besoin de ces informations, pas plus que le développeur qui n'a que les .h n'en a besoin... je veux bien croire qu'il y est un intérêt mais justement je te demande concrêtement ce qui fait que telle info est super vitale pour faire un binding et qui n'est pas présent dans un .h

comme tous les langages dynamiques
D'où le fait que je trouve cela "douteux". On a beau dire mais autant faire en statiques les vérifications qui peuvent l'être, et laisser s'exprimer la puissance dynamique du langage là où c'est vraiment utile (typiquement on manipule des informations dynamique). J'ai jamais compris cette obstination à vouloir faire en dynamique quelque chose qui peut l'être en statique : ca n'apporte strictement rien, à part une perte de vitesse et de robustesse. C'est pour ca que je trouve que c'est plus une "curiosité" qu'un réel intérêt d'avoir ce binding dynamique.

personnellement j'attribue au chargement et a la charge fixe de l'interpréteur les très mauvais score de python.
Autant le chargement on pourrait l'enlever, autant l'interprêteur, comme tu l'indiques, est "fixe". Il contribue donc au score de Python de manière "régulière".

comme cela déjà été dit plus haut la vitesse pure n'est pas forcement le principale critére de choix d'un langage sans quoi on coderait encore tous en AS
Tout est une histoire de compromis et de polyvalance. l'ASM et un langage inteprêté comme Python sont un peu les extrêmes. Je te laisses te faire tes propres conclusions.

Ben rajoute le DOCTYPE au début du fichier ^^

le client peut être un utilisateur lambda dans le cas d'une application bureautique. Me dis pas que le client il est gland de mettre son système à jour de temps à autre.

Quand au mec en prod, il aura beau faire tous les tests, s'il ne tombe pas direct sur l'appelle de méthode qui lève la fameuse exception, il sera pas plus gland et pourtant peut être qu'au bout de quelques jour ca va lui péter à la tronche...

Franchement question robustesse/sécurité on a vu mieux que de laisser ce genre de "détail" au client...

relis mon post, je donne 3 ou 4 exemples d'informations qui ne sont pas dans le .h.
J'ai bien compris, je voulais l'utilité de ces informations dans un binding.

Ça va "découvrir" l'API à la volée comme pour n'importe quel module python.

Et si la méthode n'est pas là ? Non je trouve ca franchement douteux :) hors de question de déployer un truc comme ca !
Je vois franchement pas ce que cela apporte de faire la "découverte" au dernier moment de ce genre d'info...

Oué VS 2005 pompe des trucs sur Eclipse. Et ? Eclipse n'a pompé sur personne ? VS 2005 a quand même des trucs qui tuent, à commencer par ce foutu Class Designer qui en jette. (Dommage que ce ne soit pas de l'UML mais les raisons sont à mon sens louable, cela à l'avantage de proposer une autre approche sans concurrencer son partenenaire IBM avec Rational ;) )

Je veux ouvrir un projet web ASP.NET dans VS 2003 pour lire le source ?
Faudrait que j'essai tiens :) Mais effectivement je m'attend pas à des miracles, j'avoue que la premières fois que j'avais utilisé VS.NET je trouvais ca pas top top qu'il commence par me demander où je voulais mettre mon projet dans VS... Enfin c'est sans doute ce qu'il faut sacrifier pour avoir une intégration qu'il faut bien reconnaître est plutôt bien foutu : déploiement, déboggage.

C'est tellement con qu'ils sont revenus en arrière dans VS 2005 en intégrant Cassinni :)
Le serveur qu'on code en 10 lignes ? Oué c'est vrai que ca devait pas être bien dur à intégrer direct dans VS ;)

Oui, sauf que jamais personne ne fout en prod des jar sans les tester.
Mais celui qui développe la lib n'est pas forcement le même que celui qui l'utilise ! Tu peux pas à chaque fois que tu fait une nouvelle version de ta lib passer une annonce et dire : "attention je vais mettre une nouvelle version de ma lib dans les repositories, tous ceux qui l'utilisent sont invités à recompiler leur application ! " Ca va se finir que tout le monde va utiliser sa version de lib qui marche bien dans son coin, et on aura pleins de lib en double, triple, bien difficile de mettre tout ca à jour. Enfin si je regarde les appli que j'utilise en Java c'est malheuresement ce qui se profile : à part le point commun (JDK), tout le monde embarque ses libs.

qu'il n'y a aucune norme propre en matière de packaging d'applications .NET
Euh, la norme d'encapsulation est très bien défini, c'est les .exe et les .dll avec un espace reconnu et unique : le GAC. C'est même normalisé ca. Pour les fichiers de config, la norme veut que l'on mette un truc.exe.config à côté de truc.exe. Pour IIS c'est pareil, il n'y a pas trop le choix des emplacements je trouve. Mais bon c'est vrai que le dev peut faire sa propre sauce. Mais bon cela n'a aucun impact sur la sécurité ou la robustesse.

J'ai un peu de mal à bien cerner tout de même à quoi peuvent servir ces infos : à priori tout ce que l'on cherche à générer c'est une nouvelle "vue" d'un API, quelque chose de statique et non dynamique (sinon ce n'est pas viable), et à priori je vois pas trop ce qu'on peut offrir de plus comme informations au développeur que ce qu'il y a dans les .h... ou alors même en C on a pas accès à tous les éléments... Tu pourrais préciser l'utilité dans un binding ?

ce qui permet aux langages dit "dynamiques" de générer les bindings à la volée
C'est un peut douteux dans la méthode tout de même :) Je vois mal comment déployer ce genre d'application qui vont découvrir à la volée un nouvel API :)

De plus Mono n'a non plus rien inventé
Houlà non je parle juste de ce que je connais. MS fait ca depuis très longtemps avec ses composants COM ou ActiveX.

Visual Studio... cette espèce de bouse incapable de gérer le refactoring ?
Désolé j'utilise la beta 2 de visual studio 2005 et j'ai le refactoring :)

Le machin qui oblige à lier ses projets web avec IIS
C'est le problème de l'intégration (déboggage, etc.). Si tu pars de ce principe y'a le même problème avec tomcat (de toute façon au final, sous vs comme sous eclipse tu finis par faire un script ant ou nant)

Bah si bien sûr que c'est ça. J'ai jamais dis le contraire :) J'ai juste montré qu'en Java tu n'as pas ce mécanisme, et que donc le runtime va essayer de charger la nouvelle lib et va se vautrer si jamais l'exception est levée.