Suggestions for Design-By-Contract support in Groovy 4

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Suggestions for Design-By-Contract support in Groovy 4

Damir Murat
Hi!

I'm very excited about reviving gcontracts in Groovy 4. However, I will like to suggest a few things.

I believe that besides annotations, it would be great to add explicit Design-By-Contract API too.
It might even be implemented like global methods (maybe via Groovy macro mechanism).

Here are some reasons as I see them:
- API can be more convenient if checking expressions are more complex
- IDE support should be better than for expressions in annotations.
- API can, for example, support Hamcrest matchers (sometimes they are more apparent and
  explicit than boolean expressions)
- API can support convenient pass-through methods which return checked object when it is
  valid (see valid4j library)
- direct require(), ensure(), and maybe neverGetHere() (from valid4j) APIs are placed in methods
  code without requiring mental translation about the point where annotation expressions are executed
- depending on implementation, direct API can be more code coverage friendly, which is very important
  either for asserts (not covered well by Jacoco, for example) or DBC APIs
- On the negative side, annotations might be more apparent and are displayed in Groovydoc. That last
  point maybe can be addressed by some Groovy and Groovydoc magic, I guess.

I found varify4j (http://www.valid4j.org/http://www.valid4j.org/concepts.html) being an excellent
example of an API based DBC library. Of course, being a pure Java library, it lacks some Groovy magic
like better error messages that should include real expressions used in code.

Please, take into consideration that I didn't yet look at Groovy 4. I only read release notes.

Tnx,
Damir Murat
Reply | Threaded
Open this post in threaded view
|

Re: Suggestions for Design-By-Contract support in Groovy 4

paulk_asert
Administrator
Thanks Damir,

There are certainly a great many interesting topics in this area. We are certainly keen to explore a few different things.

An api might be something to consider, although Groovy gets a long way just adding assert statements as needed.

You can also go all out and look at supporting some of the features from say JML:
public abstract class Heavyweight {
    protected boolean P, Q, R;
    protected int X;

    /*@ protected behavior
      @   requires P;
      @   diverges false;
      @   assignable X;
      @   when \not_specified;
      @   working_space \not_specified;
      @   duration \not_specified;
      @   ensures Q;
      @   signals_only Exception;
      @   signals (Exception) R;
      @*/
    protected abstract int m() throws Exception;
}
But perhaps not all of that straight away! :-)

The archived GContracts project actually contained some additional enhancements to Groovydoc (gcontracts-doc subproject) which summarised class invariants and pre & post conditions. We haven't brought that across yet but it's something we might consider doing. It would need to be updated since it is based on the old Groovydoc (old parser).

Cheers, Paul.


On Mon, Sep 28, 2020 at 8:03 PM Damir Murat <[hidden email]> wrote:
Hi!

I'm very excited about reviving gcontracts in Groovy 4. However, I will like to suggest a few things.

I believe that besides annotations, it would be great to add explicit Design-By-Contract API too.
It might even be implemented like global methods (maybe via Groovy macro mechanism).

Here are some reasons as I see them:
- API can be more convenient if checking expressions are more complex
- IDE support should be better than for expressions in annotations.
- API can, for example, support Hamcrest matchers (sometimes they are more apparent and
  explicit than boolean expressions)
- API can support convenient pass-through methods which return checked object when it is
  valid (see valid4j library)
- direct require(), ensure(), and maybe neverGetHere() (from valid4j) APIs are placed in methods
  code without requiring mental translation about the point where annotation expressions are executed
- depending on implementation, direct API can be more code coverage friendly, which is very important
  either for asserts (not covered well by Jacoco, for example) or DBC APIs
- On the negative side, annotations might be more apparent and are displayed in Groovydoc. That last
  point maybe can be addressed by some Groovy and Groovydoc magic, I guess.

I found varify4j (http://www.valid4j.org/http://www.valid4j.org/concepts.html) being an excellent
example of an API based DBC library. Of course, being a pure Java library, it lacks some Groovy magic
like better error messages that should include real expressions used in code.

Please, take into consideration that I didn't yet look at Groovy 4. I only read release notes.

Tnx,
Damir Murat
Reply | Threaded
Open this post in threaded view
|

Re: Suggestions for Design-By-Contract support in Groovy 4

Damir Murat
Tnx for replaying, Paul

I'm cheering for API as a bonus :-) Comparing to assert statements, I found it a bit more 
expressive for DBC context. But it can be considered just a stylistic issue.

My biggest complaint about "assert" statements is the lack of complete support for them 
in Jacoco code coverage. To my experience, it is impossible to write "assert" statement 
with 100% branch coverage. And this is very unfortunate when looking in a coverage report 
for a bigger project since false warnings from "assert" statements hide parts in code that 
really need more attention.

When I was scratching my head how to deal with that code coverage problem, I remembered 
almost forgotten DBC approach. I implemented a few Groovy macro methods to cover what is 
most important to me (namely, "require" precondition checking). Now I have simple DBC 
precondition checking and correct coverage reports, plus some IDEA GDSL scripts to add IDE 
auto code completion. If you are interested in the implementation, please take a look 
at https://github.com/croz-ltd/klokwrk-project and its modules "klokwrk-lang-groovy-contracts-simple" 
and "klokwrk-lang-groovy-contracts-match". Suggestions are very welcome, of course :-)

When adding all these small things up, I believe it is an improvement over using "assert" 
statements. At least for my purposes. When I finally saw the Groovy 4 road map, I was excited 
about DBC support and was hoping that DBC API can be taken under consideration as well :-) 
I hope that I explained above well enough why that is.

Tnx