Snark_Boojum a écrit 579 commentaires

Damien n'est pas "un" développeur gnomemeeting ; c'est le patron!

D'ailleurs, s'il voulait bien me répondre sur l'api du composant DBUS qu'on avance un peu ;-)

Snark

Mieux: un bâton de dynamite allumé en suppositoire avant d'aller se coucher, et plus de problème dès le lendemain!

Snark

Les vrais profs de maths utilisent déjà latex avec leur éditeur favori, ou texmacs/lyx quand ça leur convient...

Snark

C'est pas du tout pareil de faire passer de petits messages ou de jolis flux ; il n'y a pas du tout les mêmes contraintes!

Snark

Le vrai port est en cours... ça va au rythme où vont les volontaires qui font le portage: ça dépend de leur temps libre.

Snark

Je rêve!? Parler de téléphone sous GNU/Linux comme une nouveauté alors que gnomemeeting fait ça depuis bien longtemps... avec la vidéo en plus si on veut!

Pour le lien avec gaim: c'est pas une bonne idée de vouloir tout mettre dans la même application ; il vaudrait mieux que deux applications coopèrent. Le problème c'est que les développeurs gaim ont l'air plus intéressés par le développement de leur propre truc que par la coopération...

Gnomemeeting ne supporte que h323 pour le moment (ce qui est déjà pas mal), mais le support sip devrait arriver vers la fin de l'année (pour l'instant la lib de base ne fait pas de vidéo ; ça ferait une régression) ; avec un peu de chances le port sous win32 sera aussi prêt...

Snark

avec xprt-xprintorg, ça marche tout seul...

Snark

Non seulement on n'a pas d'explication de ce qu'il est quand on ne le sait pas (ce n'est pas exactement un dévermineur, même s'il aide à faire la chasse aux bogues) ; mais en plus on a droit à tout un ChangeLog en anglais là où un lien aurait suffi.

Bref, bof.

Firefox a un plugin pour visualiser les sites "comme IE" ; je ne sais pas ce qu'il vaut, mais c'est probablement une meilleure approche que faire tourner un logiciel non-libre et plein de bogues.

Très informatif effectivement... était-il utile de le donner?

Arf, moi j'en suis resté au aschtitipi et eftipi...

On peut en avoir où du htpp ?!

Snark

Plein d'archis, plein d'archis... avec X, je me connecte à la vieille machine pourrie (non, je ne dirais pas que c'est un *beep*), et je m'envoie l'affichage de l'application qui a connu les dinosaures!

Certes, à la maison je n'ai que du GNU/* (plus de *BSD malheureusement), donc ça couvrirait mes besoins (pour peu que ce soit aussi facile à utiliser que "slogin -X").

Snark

Il passe en réseau maintenant DirectFB? Avec une norme bien supportée sur plein d'archis et tout et tout?

Sans ça je ne vois pas trop l'intérêt...

Snark

En fait, demander à ce que les fabricants de matériel soient obligés de fournir les specs... libre à eux d'aussi proposer des pilotes pour les systèmes les plus en vogue.

Snark

Mais je ne veux pas changer affiche(), puisque le but de l'héritage est justement de réutiliser le code! En plus, elle est très bien cette fonction: elle prend un objet de type A et appelle sa méthode toto. Je ne vois pas pourquoi elle aurait besoin d'être réécrite, surtout pour la restreindre aux objets de type B qui ne sont qu'un petit cas particulier des objets auxquels je veux l'appliquer!

Par ailleurs, ce n'est pas le problème de la classe de base qui a gêné pour pwlib. C'est avec le nouveau code que les problèmes sont apparus: comme les classes de base n'avaient pas prévu d'être héritées, il a fallu flanquer des virtual dans tous les coins pour obtenir un truc qui marche correctement. Apparemment il fallait connaître les futurs besoins avant de les avoir...

Ce que j'essaie d'expliquer depuis le début, c'est que la normalité quand on veut faire de l'héritage, c'est coder proprement ses classes de base pour faire ce qu'on veut dans un premier temps. Et dans un deuxième temps, quand de nouveaux besoins apparaissent, on hérite, on recode ce qu'il faut, éventuellement en signalant explicitement au compilateur qu'on modifie une méthode existante et ça marche *sans retoucher l'ancien code*. Ça c'est de l'héritage sérieux, et c'est un des ingrédients essentiels pour qualifier un langage 'd'orienté objets'. À partir du moment où il faut aller trifouiller l'ancien code pour faire marcher le nouveau, on ne peut pas dire que l'on gagne grand'chose à utiliser un langage 'à classes'...

Enfin, concernant le fait que les créateurs de langage soient des clowns: ça ne me semble pas si impossible que ça. Je connais au moins un architecte qui a conçu au moins un bâtiment dont une partie est à la fois accessible 24/24 7/7 et... dépourvue de toilettes!

Snark

Oui, et justement mon exemple montre qu'en C++, le message n'arrive pas toujours à l'objet: on prend un objet de type B (donc de type A), on lui envoie le message 'toto' et c'est le bout de code des objets de type A (donc pas forcément B!) qui est appelé...

Snark

Bon, alors le C# est plus mauvais que je ne pensais ; je ne me souvenais que du fait que la classe héritante disait comment marchait l'héritage (ce qui est normal). Si la classe qui sert de base doit aussi le déclarer, c'est une horreur.

C'est marrant, mais le coup des APIs du genre FILE*, c'est justement ce qu'on utilise dans le code de gnomemeeting... qui est à la base en C++ ! [Hum! D'ailleurs, il reste des endroits qui ne respectent pas encore cette organisation ; encore du boulot pour bibi pendant que le patron se dore la pilule en Italie ;-)]

L'échantillon de programme C++ modifié en passant des pointeurs montre très bien le comportement que j'exècre, donc mon exemple tient un minimum la route quand on n'y met pas trop de mauvaise foi! ;-)

Si l'héritage n'est accessoire et "pour débutant" que pour les programmeurs C++, c'est justement parce qu'il est si problématique avec ce langage. Les malheureux sont enfermés dans une caverne platonicienne! J'ajoute néanmoins qu'il n'est pas impossible: la pwlib a un bel arbre généalogique de classes (qui merdouille dès qu'on veut y ajouter quelque chose, certes, mais ça c'est l'effet C++) (http://www.openh323.org/docs/pwlib/HIER.html(...)).

Dans les langages qui ne font pas semblant d'être OO, l'héritage est facile et donc très utilisé (voir par exemple http://www.gobosoft.com/(...)).

Snark

On n'a pas besoin de la notion d'objet pour mettre des apis autour des données... par contre, pour faire l'héritage, c'est essentiel.

Le C# n'a pas du tout le même genre de mécanisme que le C++: autant il est naturel que l'héritier précise explicitement qu'il est en train de redéfinir une méthode (après tout, on est en train de parler d'héritage, donc on fait le tri entre ce qu'on garde et ce qu'on change!) ; autant pour le C++, c'est le parent qui doit dire au compilo que ça peut se produire!

Enfin, je n'ai pas doublement faux, comme l'exemple suivant le montre:
* une classe A a une méthode 'toto' qui affiche "Hello world!";
* une fonction 'affiche' qui traîne quelque part reçoit un objet de type A et appelle sa méthode toto;
* on veut un objet de type A mais qui affiche en français "Salut tout le monde!" avec sa méthode 'toto' ; facile, on hérite et on redéfinit!
Avec un vrai langage à objets, ceci marche sans problème et sans surprise. Avec le C++, par contre, non (et sans message d'avertissement du compilateur). Pourquoi? Tout simplement parce que la classe A n'a pas déclaré/défini sa méthode 'toto' comme étant 'virtual', ie: si la classe parente ne dit pas qu'elle peut être héritée, elle ne l'est pas correctement. Ma conclusion est donc: 1) il faut le dire explicitement; 2) c'est avec 'virtual' qu'on le dit.

Je réaffirme donc mon propos: certes on peut faire de l'objet avec le C++, mais ça ne lui est pas naturel!

Snark

Alors pour clarifier les choses:
* gnomemeeting utilise le standard h323 pour les communications réseau ;
* h263 est l'un des codecs vidéo que l'on peut utiliser pour coder les flux vidéos utilisés dans une connexion avec gnomemeeting;
* le support h263 dans openh323+gnomemeeting a été présent un certain temps dans le cvs, avant d'être retiré la semaine dernière par crainte de ne pas être tout à fait net vis-à-vis des brevets (il réapparaitra probablement quand l'api de codecs vidéos génériques sera en place).

J'espère que ça aide,

Snark

Bien concevoir les interfaces ne suffit pas avec le C++, justement: si on n'a pas mis de 'virtual' partout, il va passer par l'interface de la classe parente et pas par celle de l'objet sur lequel on l'applique. En somme, c'est un langage "à classes" plutôt qu'un langage objet: on lui a dit qu'un truc pouvait être de type A, alors il le traite comme tel, même si en réalité l'objet vivant qu'on lui amène est de type B et a réimplémenté une partie de l'interface.

Pour moi la réutilisabilité via héritage est absolument essentielle pour parler de langage à objet. Sinon quel est l'intérêt de distinguer par rapport aux autres langages?

Oui, on peut faire de l'objet en C++ (avec des virtual de partout), oui on peut faire de l'objet en C (exemple: glib-gobject-gtk) ; en fait on peut faire du truc genre objet dans à peu près n'importe quel langage.

Je réaffirme donc: C++ n'est pas un langage à objets. On peut le forcer à en faire, mais il faut le prévoir.

PS: la pwlib (bibliothèque sur laquelle s'appuie gnomemeeting) est en C++, avec des classes et de l'héritage simple (ie: les classes ne réimplémentent pas ce qu'il y a dans leurs parentes -- sauf cas très exceptionnel) à gogo. Mettre au point un système de modules pour les pilotes matériels a été une horreur, parce que ça nécessitait du vrai héritage: il a fallu reprendre *tous* les étages... question réutilisabilité, on peut difficilement appeler ça une réussite.

Malheureusement si, on sait: elles vont apparaître à l'exécution pour les utilisateurs ; elles auront soigneusement évité de se faire remarquer à la compilation ou lors des tests!

Snark

Pour moi l'idée centrale pour qualifier un langage d'orienté objets, c'est l'héritage car il permet de réutiliser du code de façon élégante.

Le C++ n'entre pas dans cette définition, parce que pour faire de l'héritage, il faut le demander explicitement (mot-clef 'virtual'), sinon les choses merdent (et c'est une joie intense à déverminer).

Snark

Hmmm... voyons voir: eiffel, java et ocaml me semblent effectivement des langages objets ; par contre le C++... Quelle est l'andouille qui a dit ça?!

Snark

Tester le hurd n'est pas une terrible gageure: c'est un logiciel libre. Il n'y a pas besoin d'hypothéquer tout (mobilier, immobilier, organes, etc) ce qu'on possède pour l'utiliser!

Snark

Hmmmm... peut-être qu'ils accepteraient un patch si quelqu'un leur proposait?

Snark