Laurent Deniau wrote:

Cette relation de *polymorphisme* est necessaire meme dans les langages
OO, ce n'est donc pas un critere.

Je ne comprends pas ce que tu veux dire ici.

C:
struct Derived { struct Base; ... };
[ ... ]

Oui, en écrivant d'une certaine façon les structures de données, tu peux
effectivement implémenter une forme d'héritage et par là pouvoir simuler le
polymorphisme. Si tu veux rendre transparent ceci, tu as à écrire un
framework qui implémente les mécanismes objet pour C (cf. GTK+ avec GObject
par exemple). Ce qui est différent d'un "langage qui supporte nativement"
pour reprendre ton expression :).

Je ne parle évidemment pas de C++ ou d'ObjC qui eux supportent les concepts
objets d'héritage, de délégation (pour ObjC) et de polymorphisme.

seulement de polymorphisme (au moins deux cas dans la norme: le
recouvrement d'aggregation a l'offset zero et les flexibles arrays).

?. Je n'appelle pas ça du polymorphisme. A la rigueur une ressemblance ou
simulation de ce dernier.

Qu'est ce que tu entends par "on pense les exceptions différemment".

Dans les langages objet de masse (C++, Java, etc.), et dans d'autres, les
exceptions sont des classes d'objets à définir et à lever explicitement.
Dans Java, on doit en plus spécifier dans la signature des méthodes les
exceptions qui peuvent intervenir.
En Eiffel, les exceptions ne sont que des "signaux" issus d'une violation de
contrat (bien que l'on peut en lever un explicitement). Donc, lorsque tu
écris une classe d'objets, tu penses tes cas exceptionnels (ce que devrait
être une exception) en termes de contrats. Par exemple, dans le cas d'une
ouverture de fichier (exemple très simplifié):
class FILE
....
feature
   open(filename: STRING)
      require
         filename /= Void and not filename.is_empty
      do
         ...
      ensure
         is_open
      end
end

Si l'ouverture de fichier échoue, is_open est toutjours à false et donc une
exception est levée par le runtime parce que la post-condition (le contrat
de la routine à la fin de son exécution) n'est pas respectée.

- closures, c'est essentiellement un probleme de gestion memoire qui se
resout par un comptage de reference sur objet dynamique.

Je ne crois pas car lorsque tu passes d'un appel à un autre, entre temps
ton compteur de référence peut-être à 0 et là bye bye. Une implémentation

Je me suis mal exprime:

1) si les objects sont alloues sur le tas (ou statiques/globaux mais pas
automatiques), c'est ce que j'entendais par dynamique.
2) si chaque objet supporte le comptage de reference (ou le langage
utilise un GC)

Ok.

Mais faut pas se leurrer. Simuler un mécanisme ou un principe ne veut pas
dire le supporter (supporter nativement comme tu dis :) ). Car, en effet,
ceci reste de la simulation, ou une implémentation explicite et souvent
limitée d'un mécanisme en utilisant les propriétés du langage
(polymorphisme et closure pour ne citer que ces deux avec le C).