[Kos-dev] Progressions du WE

[Thomas Petazzoni]

>   - [pinaillage] En general, on parle de classe "abstraite" plutot que
>     "virtuelle". Peut-etre qu'il faudrait que les interf. virtuelles
>     s'appellent "abstraites" ?


Bin, on a appelle ca virtuelle, parce 'virtual interface' ca faisait 
plutot class, c'est tout. Juste une question d'inspiration. Julien et 
moi ne sommes pas vraiment familier avec les langages objets, alors 
impossible de savoir comment on appelle ca d'habitude.


>   - Pour quelle raison une interface ne peut-elle pas heriter d'une
>     autre interface (non virtuelle) ? Est-ce que c'est pour ne pas
>     compliquer les choses lors de la construction/destruction (ie pas
>     d'imbrication de constructeurs/destructeurs) ?


Nan, simplement parce qu'on ne voit pas le cas ou une interface a besoin 
d'heriter d'une autre interface dans la mesure ou une interface 
virtuelle peut eventuellement definir une implementation pour certaines 
de ces methodes.
Il ne nous ai donc pas apparu necessaire d'autoriser l'heritage entre 
interfaces, ce qui compliquerait pas mal de choses.


>   - Je ne pige pas la difference entre private ("donnees propres a
>     chaque instance") et resource ("les donnees dont les instances de
>     l'interface ont besoin pour manipuler chaque entite dont le
>     translator est une instance de cette interface"). En fait, a
>     relire, c'est plus cette definition de resource que je ne
>     comprends pas. A lire l'exemple qui suit, je ne vois pas la
>     difference entre offset et donald de mickey : il s'agit d'une
>     donnee d'une instance d'interface (qu'on appelle "translator" dans
>     le texte qui va avec "resource") qui est soit "propre a chaque
>     instance" (donald : private), soit qui "correspond a une variable
>     dans ses propres donnees" (offset : resource). Quelle est la
>     difference ?


Private sont les donnees propres a l'instance par exemple l'instance 
ext2 pour le disque dur /dev/hda4. Les donnees resource sont les donnees 
propres a chaque resource de cette instance, aka chaque fichier ouvert, 
ayant pour translator cette instance. C'est dont TOTALEMENT different. 
Ainsi l'instance ext2 pour le disque /dev/hda4 peut avoir une variable 
private 'partition' qui contient /dev/hda4, pour indiquer que cette 
instance de ext2 est lie au disque /dev/hda4.
D'autre part, CHAQUE ouverture de fichier dans cette partition, amene a 
creer une resource dont le translator est cette instance. Et CHAQUE 
fichier ouvert doit disposer d'un 'offset' par exemple.
J'espere que mon explication, est assez claire, meme si elle est un peu 
obscure quand meme :o)


>   - Le 'shared' correspond au 'static' du C++ (peut-etre meme du
>     Java), meme si dans le cas present il s'agit d'un delimiteur de
>     section, alors qu'en C++/Java(?) il s'agit d'un attribut de
>     variable. Je sais bien que le mot clef 'static' a 1565732
>     significations differentes en C. Est-ce qu'on garde 'shared' au
>     lieu du plus habituel 'static'.


Shared = partage, et c'est vraiment cet esprit la qu'on souhaite. Pour 
moi static implique plus "je garde la valeur a chaque appel de la 
methode", or ce n'est pas ca qu'on veut exprimer. Shared est 
l'identifiant du bloc de declaration des variables PARTAGEES entre 
toutes les instances de la meme interface. Ex : l'interface ext2 peut 
avoir en shared une variable nb_partition, qui contient le nombre de 
partitions montees grace a cette interface. Cette variable est 
clairement partagee entre toutes les instances.


>   - Je vois que 'this' existe. Mais je me dis aussi qu'il serait bien de
>     pouvoir acceder aux methodes parentes en cas de surcharge
>     d'operateur. La methode habituelle du C++ (cast) risque de
>     compliquer la moulinette de traduction. C'est pour ca qu'avoir un
>     pointeur 'parent' serait aussi pas mal.


Ca coute pas grand chose, et ca peut toujours servir, pourquoi pas !


>   - Est-ce qu'on sera toujours oblige d'ecrire 'this->name' pour
>     acceder a la variable 'name' ?


Oui. Deja on a simplifie a mort, en disant que ecrire this->qquechose ca 
permettait d'acceder a un qquechose se trouvant dans shared 
(correspondant a interface_data), dans private (correspondant a 
instance_data), dans infos ou dans resource et meme dans methods. Ca me 
parait deja pas mal simplifie, et je pense que dire name = this->name 
c'est pas terrible terrible, risque de confusion entre les variables...


> Voila les quelques questions sur le document meme. Et maintenant,
> comment cree-t'on une instance ? Comment l'utilise-t'on ? Peut-on
> acceder a certaines methodes des interfaces sans les instancier ?


Comment cree-t-on une instance : c'est la tower babel (qui sera ecrite 
en K) qui le fera, comme actuellement.
Comment l'utilise-t-on : le mec veut faire write sur un fichier, il 
passe donc la resource (equivalent au file descriptor) a la libc, qui 
appel alors directement la methode. C'est possible car la resource 
contient un pointeur vers le transalor (cad l'instance), et que cette 
instance contient des pointeurs de methodes.


> Mais j'aime bien, oui, j'aime bien. Malgre les apparences, le truc qui
> me chiffonne le plus, c'est l'assymetrie entre interfaces abstraites
> (non instanciables, heritables), et "concretes" (non heritables,
> instanciables).


Bin c'est voulu....

Amicalement,

Thomas

PS : finalement je rentre pas le mercredi soir tard, mais le mercredi 
dans la journee... donc si tu veux venir plus tot.. Je crois que tu as 
deja prevu qque chose, mais on ne sait jamais !

-- 
PETAZZONI Thomas
thomas.petazzoni@meridon.com
ICQ : 34937744
Projet KOS : http://kos.enix.org