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 <damir.mu...@gmail.com> 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
>
