Dans les trois articles, un objet est d'abord décrit par une classe, (``classe'' dans [Gra89], ``métaobjet de base'' dans [MMC95], ``classe'' ou ``description par défaut'' dans [Mez96]); des métaobjets ``modifient'' alors cette description de base (dans [Gra89], des ``métaclasses'', dans [MMC95], des ``métaobjets composables à gauche'' dans [Mez96], des ``descriptions d'ajustement'').
La répartition des bases et modifications entre métaniveaux se fait différemment dans les articles:
Cette différence de répartition en soi ne semble qu'une différence arbitraire de vocabulaire, et témoigne d'une absence de théorie claire en ce qui concerne la réflexivité et l'emboîtement des méta-niveaux, ce qui rend floue l'attribution de chaque caractéristique à un niveau de métalangage.
De manière plus importante, Graube tente de définir des règles formelles que le système pourrait vérifier lui-même, mais n'en expose que le principe général, étant finalement bloqué par les complications sémantiques nécessités par la déclaration et la propagation des hypothèses sur les métaclasses.
Mulet et al., en comparaison,
laissent au programmeur la charge
complète d'assurer la cohérence du système,
ce pour quoi ils ne donnent pas d'indice dans leur méthodologie;
c'est même au programmeur de gérer la composition des métaobjets
en définissant la réponse au message compose-with
!
Il apparaît alors que [MMC95] définit
une interface de bas niveau à la combinaison de méta-objets,
qui ne fait que repousser le problème sans le résoudre:
les auteurs interdisent à la non-orthogonalité des méta-objets d'apparaître
dans leur interface méta, mais ceux-ci sont toujours libres d'interférer
arbitrairement dans le niveau de base, sans qu'une solution ne soit proposée.
Enfin, Mezini semble demander de l'utilisateur qu'il spécifie lui-même, dans des ``métaprogrammes'', comment assurer la cohérence du système, autre façon de repousser le problème sans le résoudre; la méthode de Mezini a au moins l'avantage de prévoir une méta-interface qui permette cette résolution.
[Gra89] est le seul article à vraiment tenter de donner un sens à la combinaison simultanée de métaclasses, mais il n'aboutit pas; [MMC95] et [Mez96], tout en reconnaissant les problèmes soulevés, les fuient en proposant une composition sérielle de filtres, sans pouvoir s'assurer que ceux-ci n'interfèrent pas entre eux.
Dans les trois cas, des préjugés informels ont remplacé une formalisation explicite.
Les règles que Nicolas Graube souhaite voir propagées par ses objets sont typiquement des règles de sous-typage, et non pas d'héritage: un sous-type serait assuré de conserver toutes les hypothèses sur les instances du type originel, tandis qu'un type hérité non-trivial est assuré d'en modifier certaines; Graube trébuche sur cette difficulté, et avoue en fin d'article qu'il n'arrive pas, dans le cadre de l'héritage, à trouver où déclarer les contraintes, et que l'analyse sémantique du système obtenu est un travail très ardu; la seule application qu'il arrive à montrer consiste à spécifier la restriction abusive de la formation de classes à l'héritage simple.
Dans l'article [EST95], une équipe de recherche est arrivée à donner une sémantique formelle de l'héritage en passant par le sous-typage et les types polymorphes paramétriques; le contraire semble impossible, l'héritage étant à la fois plus compliqué et moins expressif que la combinaison des deux concepts précédents.
Nous pensons qu'abandonner l'héritage et utiliser le sous-typage auraient grandement simplifié le problème et permis d'aboutir à une algèbre de types assez simple pour être décrite dans un article et implémentée dans un langage. Cela ne suffirait certes pas à résoudre le problème de combinaison, mais l'aurait débarassé des obstacles qui ont arrêté Graube.
Mulet et al. confondent visiblement composition et application, essayant d'implémenter l'un par l'autre: ils décrivent en terme de composition l'application de mixins, et proposent de réaliser la composition par l'envoi d'un message de composition à l'un des métaobjets. La composition d'objets implique naturellement que ces objets soient des fonctions, et les auteurs introduisent eux-mêmes la notion de ``trou'' dans une définition, mais enfermés dans le formalisme du passage de messages, ils ne voient pas que l'introduction explicite de métaobjets fonctionnels d'ordre supérieur ou foncteurs, trivialiseraient leurs problèmes de mise en place d'une composition.
Mulet et al. prônent l'orthogonalité des concepts de programmation, mais font appel aux notions visiblement voisines de spécialisation et agrégation, alors qu'ici encore, des constructeurs d'ordre supérieur pour des types paramétriques et points fixes rendraient orthogonaux agrégation de types et résolution de type à passer en paramètre. Les foncteurs et modules d'ordre supérieur ont été décrits, entre autre, dans [Blu94] et [Ler95].
Encore une fois, une telle simplification ne suffirait pas à résoudre le problème de combinaison des métaobjets, mais aurait au moins permis de formaliser proprement les mécanismes utilisés, pour pouvoir discuter de leur adéquation au problème traité.
Mezini reprend à d'autres auteurs des problématiques et des propositions intéressantes [IB+94] [OI94], mais en fait un mélange plutôt qu'une synthèse. L'article prétend trouver une solution pour combiner des métaobjets, mais le peu qu'il ressort des explications floues de l'auteur laisse le lecteur dubitatif. L'évaluation de l'approche proposée dans la section 5 est abusivement optimiste: