groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <>
Subject GContracts Overview
Date Mon, 03 Aug 2020 14:38:09 GMT
Since there is currently a proposal on the dev mailing list whether to 
include the design-by-contract GContracts library 
( into Groovy,  for 
everyone who has never used GContracts (or design-by-contract), and 
since most of the "info"-links on the GitHub seem to be broken, here are 
some links on the topic:

The final example in the overview article gives a good idea on how the 
design-by-contract mechanisms of pre-/postconditions 
(@Requires/@Ensures) and invariants (@Invariant) works in GConract 
(Note: The RocketAPI interface is not necessary, annotations could also 
reside directly on Rocket class methods):

import org.gcontracts.annotations.*

interface RocketAPI {
   def start()
   boolean isStarted()
   int getSpeed()

   @Requires({ started })
   @Ensures({ result - old.speed == 5 })
   def accelerate()

   @Requires({ started })
   @Ensures({ old.speed - speed == 5 })
   def brake()

@Invariant({ speed >= 0 && speed <= Integer.MAX_VALUE - 5 })
class Rocket implements RocketAPI  {

     int speed
     private boolean started

     def start() { started = true }
     boolean isStarted() { started }

     def accelerate()  {
         speed = speed + 5
         return speed

     def brake() {
         speed = speed - 5

def rocket = new Rocket()


On 03/08/2020 07:57, Paul King wrote:
> Hi everyone,
> The GContracts project (design-by-contract extension for Groovy) has 
> been archived:
> I believe there is sufficient merit in the functionality it offers for 
> us to consider taking up support of the codebase, and the project 
> owner, Andre Steingress, is happy for that transition to take place.
> We could try to re-invigorate GContracts outside the ASF but I think 
> our community where a larger pool of folks can contribute when they 
> have availability makes more sense than another single person trying 
> to take it over and then potentially running out of steam down the track.
> We could give it it's own repo and have it as a subproject but for now 
> I think it is easiest just to have it as an optional module in the 
> core repo (targeting Groovy 4). In the PR, I have marked the main 
> annotations as @Incubating for the time being. For further details, 
> see here:
> Let me know if you have any objections or alternate thoughts.
> Thanks, Paul.

View raw message