Discussion :

[white_tentacle]

Mais il n'existe (apparemment dans aucun langage impératif) aucun mécanisme qui permette d'avoir à la fois "le beurre et l'argent du beurre" en ayant tout à la fois la valeur "documentaire" et la vérification à l'exécution des préconditions / postconditions.

Il y a vraiment ça en Eiffel, pour le coup. Comme c’est intégré au langage, ça a la même valeur documentaire que la signature de la fonction.

Pour D, j’ai regardé rapidement, je trouve leur façon de faire bizarre et peu élégante du point de vue des termes choisis (assert ne signifie pas du tout la même chose que require) et de la syntaxe.

[gl]

Le problème, c'est que cela se passe au niveau du code, et, si j'ai bien compris ce que dit Gl (dis moi si je me trompe ), c'est qu'il faut dupliquer cette information au niveau de la documentation, ou, si tu préfères, au niveau de ce qui est strictement accessible à l'utilisateur.

Oui assert() c'est au niveau du code, et c'est bien une des limitations d'assert (les autres étant qu'il ne distingue pas précondition, postcondition et invariant et que c'est purement au runtime).

Mais si tu disposes dans le langage des mots-clé nécessaires et des mécanismes correspondants, ce n'est plus à l'intérieur de ton implémentation et ce n'est pas "simplement du code" (et tout cas pas plus que la signature de fonction), ce qui permet :

• A la génération de doc de les prendre en compte.
• Aux IDE de le présenter dans l'aide contextuel.
• A un humain de le lire au même titre qu'il lit le cartouche de commentaires et la signature de fonction.
• Aux compilos de tester à la compilation ce qui est statiquement vérifiable et de générer en debug le code nécessaire à vérifier le reste (en gros de générer des assert et static_assert pour vérifier toutes ces conditions).
• Aux outils de vérification de code de lever ou pas certaines alertes.
• De ne pas avoir à se répéter (avec les risques que cela induit).

Bien sur que assert existe et c'est une bonne chose. Bien sur qu'il est utilisé, parfois sous utilisé, parfois sur utilisé (ou utilisé à mauvais escient), et ca, c'est à chaque développeur de faire son propre mea culpa . Mais il n'existe (apparemment dans aucun langage impératif) aucun mécanisme qui permette d'avoir à la fois "le beurre et l'argent du beurre" en ayant tout à la fois la valeur "documentaire" et la vérification à l'exécution des préconditions / postconditions.

Comme le signale white_tentacle, on peut regarder du côté de D et de Eiffel (de toute manière dès que l'on parle de ppc, il faut regarder du côté de Eiffel).

D'une certaine manière, la notion de concept se rapproche de cette idée, mais, ils ont été abandonnés

Remis à une date ultérieur et sous une forme différente plutôt me semble-t-il.
C'est proche mais l'idée des concepts est plutôt de fournir l'interface (au sens structure et services rendus) que doit satisfaire un paramètre template.

[Iradrille]

Le problème, c'est que cela se passe au niveau du code, et, si j'ai bien compris ce que dit Gl (dis moi si je me trompe ), c'est qu'il faut dupliquer cette information au niveau de la documentation, ou, si tu préfères, au niveau de ce qui est strictement accessible à l'utilisateur.

C'est pour ça que je parlais du D, où l'on peut retrouver des choses du genre (cf doc)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
long square_root(long x)
  in
  {
    assert(x >= 0);
  }
  out (result)
  {
    assert((result * result) <= x && (result+1) * (result+1) >= x);
  }
  body
  {
    return cast(long)std.math.sqrt(cast(real)x);
  }

ou encore

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
class Date
{
  int day;
  int hour;
 
  invariant() {
    assert(1 <= day && day <= 31);
    assert(0 <= hour && hour < 24);
  }
}

(Bon la syntaxe, on aime ou pas, c'est pas très important)

Mais quelque chose du genre permet d'avoir les pré/post conditions testées dans le code et d'avoir un moyen de générer de la doc qui en tient compte.