Previous Next Table of Contents

2. Les articles en situation

2.1 Différents points de vue sur le même problème

Tout en parlant essentiellement du même sujet, et tout en suivant une même tradition de langages dits orientés-objets où l'héritage est le mécanisme privilégié de définition incrémentale des objets, les auteurs utilisent chacun un vocabulaire qui lui est propre, lié à des nuances spécifiques et à l'affiliation à un courant particulier de la recherche en la matière. Par exemple, les métaobjets à combiner sont appelés ``métaclasses'' chez Graube, ``métaobjets'' chez Mulet, Malenfant et Cointe, et ``métadescriptions'' chez Mezini; pourtant, à la lecture des articles, on discerne peu de différence de contenu entre ces termes.

Cette variété de dénomination engendre une certaine confusion chez le lecteur, et invite à se demander en quoi les légères différences conceptuelles affectent les argumentations développées. On se rend alors compte qu'une unité linguistique serait bienvenue, mais cela nécessiterait un standard reconnu, fondé sur des définitions formelles des concepts, qui n'existe pas actuellement.

2.2 Problème des définitions

A défaut d'un tel standard, le lecteur doit s'en tenir à ce qui est explicitement défini dans l'article ou les ouvrages cités en références bibliographiques à ce propos.

Définitions dans [Gra89]

Des divers auteurs, Nicolas Graube se soucie le plus de préciser le sens des termes employés: d'une part, il se place dans le cadre des langages Smalltalk, ObjVlisp, CLOS, d'où l'on peut tirer des définitions opérationnelles de classes et métaclasses, d'autre part, il tente de donner lui-même une définition de ces termes, dans la section 2 de son article.

Malheureusement, il sacrifie parfois la précision à une volonté de généralité, sans pour autant se détacher de particularités des langages à classes. Par exemple, il définit une classe comme la description de la structure et du comportement de ses instances, la structure décrivant elle-même l'état propre des instances, le comportement décrivant les méthodes s'appliquant aux instances. Cette définition est assez générale, donc, mais elle pourrait être simplifiée par une approche d'ordre supérieur que CLOS suggère, unifiant valeurs et fonctions, et ne laissant comme distinction que la résolution de portée des variables entre classe et instance; une classe ne serait plus que la description de la structure dynamique des instances.

Définitions dans [MMC95]

Mulet et al. utilisent des termes plus généraux au contenu technique plus vague (métaobjet, composition), et font appel à des métaphores qui correspondent mal aux concepts qu'ils développent ensuite: ainsi, l'auteur de l'introduction expose parfaitement en termes synthétiques le problème général de la combinaison de métaobjets, mais dès la section 1, l'article devient plus approximatif; La combinaison de métaobjets est d'abord assimilée à la composition de fonctions (pour laquelle les auteurs choisissent une convention inhabituelle sur l'ordre des arguments). Or, la composition de fonctions consiste à appliquer l'un après l'autre deux objets du premier ordre avec une contrainte de typage:

  f: 'a -> 'b
  g: 'b -> 'c
---------------
g o f: 'a -> 'c
Au contraire, la combinaison de métaobjets consiste à appliquer en même temps (ce qui est explicitement écrit dans l'introduction) des objets méta, avec une contrainte de typage plutôt du genre:
  Mb: 'a -> 'b
  Mc: 'a -> 'c
-------------------------
C(Mb,Mc): 'a -> 'C('b,'c)
La composition de fonction est encore évoquée pour modéliser l'héritage, alors que l'héritage fait intervenir deux objets de nature essentiellement différente, une classe de base et une modification que l'on y applique; la composition supposerait que les deux opérandes ainsi que le résultat soient des objets fonctionnels de nature similaire.

Définitions dans [Mez96]

L'auteur du troisième article ne donne pas de définition formelle, et les textes auquels il se réfère (notamment [OI94]) non plus; cependant, de petits exemples et explications informelles sont donnés pour éclairer les concepts développés. L'article apporte donc une certaine intuition du sujet, mais se prive de la possibilité de prouver un résultat quelconque, faute d'un cadre rigoureux de démonstration. Les choix architecturaux paraissent en conséquence arbitraires, n'étant pas justifiés: par exemple, la division entre objets et quatre catégories de métaobjets, et la séparation correspondante du système proposé en cinq espaces. Le plus gênant est qu'on ne comprend pas bien ce que l'auteur met sous les noms de ClassCombiner ou MetaCombiner, présenté comme la solution au problème; le pouvoir d'expression et le mécanisme de résolution de ces super Combinateurs restent obscurs.

2.3 Arguments

Tous les trois articles partent de la notion d'héritage comme mécanisme incontournable pour la définition d'objets. Cependant, ils divergent quant au rôle de l'héritage dans la combinaison de métaobjets.

Argument de [Gra89]

Pour Graube, c'est évidemment par l'héritage que se combinent les métaclasses: dans la section 3 de son article, il montre que si une classe hérite d'une autre, cela impose immédiatement des contraintes entre métaclasse de la nouvelle classe et celle de la classe parent; la solution de Smalltalk était que la métaclasse hérite de la métaclasse du parent; celle de CLOS, que les deux métaclasses soient égales, ce qui n'empêche pas l'existence de conflits sémantiques entre deux superclasses d'une même métaclasse. Selon Graube dans la section 4 de son article, plutôt que d'imposer une restriction grossière qui ne résoud rien, il faut établir finement les contraintes de compatibilité requises sur une nouvelle classe et sa métaclasse pour pouvoir hériter d'une classe existante.

Argument de [MMC95]

Pour Mulet et al. les métaobjets doivent se ``composer'' comme les objets, par spécialisation (terme qui reprend à la fois l'héritage des langages à classes et plus généralement les mécanismes de délégation des langages à objets), et par agrégation (terme décrivant produits cartésiens et enregistrements), la différence étant dans la propagation du lien dynamique vers le (méta)objet lors de l'invocation de méthodes. Pour pouvoir composer des métaobjets, ils laissent dans l'objet ``composé à gauche'' des ``trous'' remplis par le métaobjet ``composé à droite''.

Pour éviter les conflits entre métaobjets, ils proposent comme méthodologie la limitation volontaire des interactions entre métaobjets à un protocole à métaobjet restreint à deux messages (lookup, apply), hors desquels les métaobjets doivent être des boîtes noires n'interférant pas; un troisième message, compose-with, à la sémantique particulière, sert à composer les métaobjets. Après avoir illustré l'utilisation de cette méthodologie, les auteurs montrent comment la transporter dans le cadre de CLOS, où elle apparaît comme une restriction à l'utilisation de mixins tels que définis dans le parent FLAVORS de CLOS.

Argument de [Mez96]

Dans l'article de Mezini, la représentation d'un objet est dispersée en de multiples ``métadescriptions'', où une description par défaut est distinguée de descriptions d'ajustements. Au cours d'une présentation des principes d'implémentation ouverte, sont alors évoqués comme spécification informelle des aspects ``statiques'' et ``dynamiques'' que le système doit présenter; le concept de ``conditions limites dynamiques'' y apparaît comme déterminant pour la validité des métadescriptions.

Un modèle est alors proposé pour gérer ces descriptions dispersées en tenant compte de leur domaine de validité: des gestionnaires s'occuperont chacun d'une description, tandis que des métaprogrammes propageront dans le programme des modifications assurant la cohérence des descriptions entre elles. Les classes sont utilisées pour définir des descriptions partielles par défaut d'un objet, mais la façon dont l'héritage fait partie de la description par défaut ou de descriptions d'ajustement est peu clair. Chaque objet est alors géré individuellement par son propre MetaCombinateur qui dispose d'un ensemble dynamique de descriptions partielles à combiner, ensemble plus tard décrit comme une liste dynamique de filtres appliqués dans l'ordre.

2.4 Exemples présentés

Pour illustrer leur propos, chacun des trois articles présente des exemples d'application à l'usage des métaobjets.


Previous Next Table of Contents