Eiffel like reports for Design by Contract contracts

July 25

Posted by Brother Bill

Permalink

Brother Bill

Permalink

In Eiffel, it is trivial to get a report for Subject Matter Experts (SMEs) that will provide feedback that the DbC contracts are what they agreed to.

It would be nice to have this in D.

Does D already have this, or should this be added to DIP Ideas forum?

Imagine a sample contract for Vats (not Value Added Tax, but liquid containers.
A vat can be open, closed, full, empty, etc.

A contract for fill() might be
```
in {
  assert(!full, "vat cannot be full");
}
out {
  assert(full' "vat is full");
}
```

It would be nice to extend the assert statement to add a label such as:
```
in {
  not_full: assert(!full, "vat cannot be full");
}
out {
  full: assert(full, "vat is full");
}
```

It would be nice to generate a report for SMEs that would look like:
fill method
  require
    not full: not full, "vat cannot be full"
  ensure
    full: full, "vat is full"

Note the conversion of C style operators to Eiffel wordy operators.

The benefit is for Architects to be able to use D language for architecture, similar to what is done in Eiffel.

Of course, this will need to do it without Eiffel Multiple Inheritance, using D single inheritance and Interfaces. (I do believe that D Interfaces support DbC).

Some notes: 1. The ``Identifier :`` syntax is used for labels within a statement list. 2. The feature in question you are asking about is assertion clauses. D does not have this. https://www.eiffel.org/doc/solutions/Design_by_Contract_and_Assertions https://www.eiffel.org/doc/eiffel/Eiffel_programming_language_syntax#Assertions 3. Eiffel requires assertion clauses in the in condition (with the tag), but not in the out contract. 4. Instead of introducing new syntax specific to this task, I would suggest introduce having UDA's on statements. ``@AssertClause("more than zero") { ... }`` 5. We support the class inheritance behavior of contracts. Right now this is butting heads against our exception handling behavior and is preventing us from making certain changes (that are not necessarily better). 6. The current behavior of contracts, when they get compiled in and executed isn't what is expected currently. This needs fixing. 7. Its unlikely the behavior of interfaces wrt. method behavior (such as no default body) is going to align with what you expect. Again, I want to resolve this but it isn't on my short term list. If you come up with a concrete set of changes, then you would post it on the ideas forum as a starting point. Classes in general are on my list of things that need work, but my attention is elsewhere and that lot of work is waiting on other work done by other people to both start and finish. Specifically related to TypeInfo removal.

Forums