[Kos-dev] Re: objc

[d2]

Dans ce cas, puisque le C semble etre la meilleure approche, on peut
toujours fignoler des macros afin d'alleger l'ecriture. Dans un
premier temps, plus besoin de C-- alors. Mais il faut blinder la
conception et l'agencement des structures. gtk me semble un point de
repere de ce cote la (avec les verifications de types lors du casting
par exemple). Je n'ai pas dit "modele".

Mais tout ca manque un peu de fonctionnalites supplementaires. L'idee
d'un preprocesseur supplementaire me plaisait parce qu'elle permettait
de simplifier l'ecriture. Mais j'ai peur qu'a se lancer la-dedans on
s'ecarte trop du sujet central (OS). L'idee de reutiliser qqch qui
existe deja est bonne, mais rien ne nous convient semble-t'il...

Pour que le regret soit un peu plus amere, voila ce que j'aurais bien
aime pouvoir ecrire avec un c-- :

  babel_service soundcard : inherit multimedia_io {
    interface:
      export void set_sample_rate(int rate); /* export -> Accessible
                                                depuis cpl3 */
      void reinit_sound(); /* Inaccessible depuis cpl3 */
      int max_sample_rate;
    instance:
      void get_
      int truc, bidule;
      int sample_rate;
  };

Ca serait reecrit en les structures babel qui vont bien, avec des
copier-coller depuis les structures de multimedia_io.

Les fonctions de soundcard seraient :
  - soit celles de multimedia_io reecrites (copier-coller) pour coller
    aux structures de soundcard.
  - fonctions de soundcard seraient reecrite pour utiliser les
    structures de soundcard.

Ca se rejoint un peu. Pour donner une idee : Imaginons qu'on a la
declaration qui precede, et que multimedia_io ait une methode
resync_image();

 void soundcard#set_sample_rate(int rate) {
  this#sample_rate = rate;
  if (rate > interface(this)#max_sample_rate)
    interface(this)#max_sample_rate = rate;
  this#resync_image(); /* Equivalent a interface(this)#resync_image() */
 }

Serait reecrit en :

 void soundcard#set_sample_rate(struct babel_instance_t *instance, int rate){
   struct _soundcard_instance_t *snd =(struct _soundcard_instance_t*)instance);
   snd->sample_rate = rate;
   if (rate > snd->interface->max_sample_rate)
     snd->interface->max_sample_rate = rate;
   snd->interface->resync_image();
 }

Ca serait rajoute dans la VMT (donc declaration de la fonction en static).

Le C-- genererait une table de conversion "nom methode" -> identifiant
-> methode. Ce qui fait qu'on ferait transiter tous les appels de
fonctions/instanciation par babel.

2 points delicats :
  - Les fonctions d'allocation en memoire des structures sont generees
    automatiquement par C--. Comme en C++, les fonctions de
    construction/destruction seront appelees respectivement
    apres/avant l'allocation/desallocation.
  - 2 niveaux de constructeurs : niveau interface / niveau instance.
  - [IMPORTANT] : Le chainage des constructeur/destructeurs qui suivent les
    relation d'heritage (constructeur de multimedia_io appele avant celui de
    soundcard).

Voila. En fait, tout ca c'est surtout de la reecriture. Mais quand
meme, ca fait un peu peur de se lancer la-dedans (on risque de
s'ecarter beaucoup du sujet).

Bonne journee,

-- 
d2