GContracts Overview

[MG <mg...@arscreat.com>]

Since there is currently a proposal on the dev mailing list whether to 
include the design-by-contract GContracts library 
(https://github.com/andresteingress/gcontracts/) 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:

https://jaxenter.com/tutorial-gcontracts-a-design-by-contract-extension-for-groovy-104751.html
https://en.wikipedia.org/wiki/Design_by_contract


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()
rocket.accelerate()


Cheers,
mg


On 03/08/2020 07:57, Paul King wrote:
>
> Hi everyone,
>
> The GContracts project (design-by-contract extension for Groovy) has 
> been archived:
>
> https://github.com/andresteingress/gcontracts/
>
> 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:
>
> https://github.com/apache/groovy/pull/1337
> https://issues.apache.org/jira/browse/GROOVY-9671
>
> Let me know if you have any objections or alternate thoughts.
>
> Thanks, Paul.
>