You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Paul King <pa...@asert.com.au> on 2020/08/03 05:57:02 UTC
[DISCUSS] Proposed new optional module: groovy-contracts
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.
GContracts Overview
Posted by 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.
>
Re: [DISCUSS] Proposed new optional module: groovy-contracts
Posted by Paul King <pa...@asert.com.au>.
The ICLA has been submitted but I'll await confirmation from the secretary
before proceeding.
Cheers, Paul.
On Mon, Aug 3, 2020 at 10:48 PM Paul King <pa...@asert.com.au> wrote:
> I am chasing that up.
>
> On Mon, Aug 3, 2020 at 10:34 PM Remko Popma <re...@gmail.com> wrote:
>
>>
>>
>> On Mon, Aug 3, 2020 at 9:33 PM Remko Popma <re...@gmail.com> wrote:
>>
>>> Do we need a ICLA contributor agreement
>>> <https://www.apache.org/licenses/contributor-agreements.html>?
>>>
>> I meant from Andre. Or does he already have an ICLA on file with ASF?
>>
>>
>>>
>>> On Mon, Aug 3, 2020 at 9:13 PM Paul King <pa...@asert.com.au> wrote:
>>>
>>>> I am inclined to do a fresh start since as others have pointed out we
>>>> do have the old repo. The old code is 3-clause BSD license but this
>>>> contribution is being made under Apache license. Also, the code was
>>>> refactored somewhat to be more consistent with the current code base
>>>> styling and tweaked to work better with Groovy 3 and CompileStatic.
>>>>
>>>> Cheers, Paul.
>>>>
>>>> On Mon, Aug 3, 2020 at 10:01 PM Guillaume Laforge <gl...@gmail.com>
>>>> wrote:
>>>>
>>>>> Agreed, but 1) it's definitely not the same size of project (only 300
>>>>> commits for GContracts), and 2) the history is not lost since it stays in
>>>>> the old project (even if it's less convenient to have to dig in another
>>>>> location). Now that said, perhaps some of our ASF INFRA admins have some
>>>>> super git abilities and know how to import some external sources with their
>>>>> history?
>>>>>
>>>>> On Mon, Aug 3, 2020 at 12:26 PM Jochen Theodorou <bl...@gmx.org>
>>>>> wrote:
>>>>>
>>>>>> On 03.08.20 11:50, Guillaume Laforge wrote:
>>>>>> [...]
>>>>>> > And honestly, it's pretty rare that we have to dig in anyway.
>>>>>>
>>>>>> that could be true in case of gcontracts.
>>>>>> For groovy-core it certainly is not true. Especially if the code part
>>>>>> I
>>>>>> am looking at is unfamiliar it is very important to get why some
>>>>>> things
>>>>>> are how they are. That is also why it was so important to have all the
>>>>>> old codehaus issues in apache.
>>>>>>
>>>>>> bye Jochen
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Guillaume Laforge
>>>>> Apache Groovy committer
>>>>> Developer Advocate @ Google Cloud Platform
>>>>>
>>>>> Blog: http://glaforge.appspot.com/
>>>>> Twitter: @glaforge <http://twitter.com/glaforge>
>>>>>
>>>>
Re: [DISCUSS] Proposed new optional module: groovy-contracts
Posted by Paul King <pa...@asert.com.au>.
I am chasing that up.
On Mon, Aug 3, 2020 at 10:34 PM Remko Popma <re...@gmail.com> wrote:
>
>
> On Mon, Aug 3, 2020 at 9:33 PM Remko Popma <re...@gmail.com> wrote:
>
>> Do we need a ICLA contributor agreement
>> <https://www.apache.org/licenses/contributor-agreements.html>?
>>
> I meant from Andre. Or does he already have an ICLA on file with ASF?
>
>
>>
>> On Mon, Aug 3, 2020 at 9:13 PM Paul King <pa...@asert.com.au> wrote:
>>
>>> I am inclined to do a fresh start since as others have pointed out we do
>>> have the old repo. The old code is 3-clause BSD license but this
>>> contribution is being made under Apache license. Also, the code was
>>> refactored somewhat to be more consistent with the current code base
>>> styling and tweaked to work better with Groovy 3 and CompileStatic.
>>>
>>> Cheers, Paul.
>>>
>>> On Mon, Aug 3, 2020 at 10:01 PM Guillaume Laforge <gl...@gmail.com>
>>> wrote:
>>>
>>>> Agreed, but 1) it's definitely not the same size of project (only 300
>>>> commits for GContracts), and 2) the history is not lost since it stays in
>>>> the old project (even if it's less convenient to have to dig in another
>>>> location). Now that said, perhaps some of our ASF INFRA admins have some
>>>> super git abilities and know how to import some external sources with their
>>>> history?
>>>>
>>>> On Mon, Aug 3, 2020 at 12:26 PM Jochen Theodorou <bl...@gmx.org>
>>>> wrote:
>>>>
>>>>> On 03.08.20 11:50, Guillaume Laforge wrote:
>>>>> [...]
>>>>> > And honestly, it's pretty rare that we have to dig in anyway.
>>>>>
>>>>> that could be true in case of gcontracts.
>>>>> For groovy-core it certainly is not true. Especially if the code part I
>>>>> am looking at is unfamiliar it is very important to get why some things
>>>>> are how they are. That is also why it was so important to have all the
>>>>> old codehaus issues in apache.
>>>>>
>>>>> bye Jochen
>>>>>
>>>>>
>>>>
>>>> --
>>>> Guillaume Laforge
>>>> Apache Groovy committer
>>>> Developer Advocate @ Google Cloud Platform
>>>>
>>>> Blog: http://glaforge.appspot.com/
>>>> Twitter: @glaforge <http://twitter.com/glaforge>
>>>>
>>>
Re: [DISCUSS] Proposed new optional module: groovy-contracts
Posted by Remko Popma <re...@gmail.com>.
On Mon, Aug 3, 2020 at 9:33 PM Remko Popma <re...@gmail.com> wrote:
> Do we need a ICLA contributor agreement
> <https://www.apache.org/licenses/contributor-agreements.html>?
>
I meant from Andre. Or does he already have an ICLA on file with ASF?
>
> On Mon, Aug 3, 2020 at 9:13 PM Paul King <pa...@asert.com.au> wrote:
>
>> I am inclined to do a fresh start since as others have pointed out we do
>> have the old repo. The old code is 3-clause BSD license but this
>> contribution is being made under Apache license. Also, the code was
>> refactored somewhat to be more consistent with the current code base
>> styling and tweaked to work better with Groovy 3 and CompileStatic.
>>
>> Cheers, Paul.
>>
>> On Mon, Aug 3, 2020 at 10:01 PM Guillaume Laforge <gl...@gmail.com>
>> wrote:
>>
>>> Agreed, but 1) it's definitely not the same size of project (only 300
>>> commits for GContracts), and 2) the history is not lost since it stays in
>>> the old project (even if it's less convenient to have to dig in another
>>> location). Now that said, perhaps some of our ASF INFRA admins have some
>>> super git abilities and know how to import some external sources with their
>>> history?
>>>
>>> On Mon, Aug 3, 2020 at 12:26 PM Jochen Theodorou <bl...@gmx.org>
>>> wrote:
>>>
>>>> On 03.08.20 11:50, Guillaume Laforge wrote:
>>>> [...]
>>>> > And honestly, it's pretty rare that we have to dig in anyway.
>>>>
>>>> that could be true in case of gcontracts.
>>>> For groovy-core it certainly is not true. Especially if the code part I
>>>> am looking at is unfamiliar it is very important to get why some things
>>>> are how they are. That is also why it was so important to have all the
>>>> old codehaus issues in apache.
>>>>
>>>> bye Jochen
>>>>
>>>>
>>>
>>> --
>>> Guillaume Laforge
>>> Apache Groovy committer
>>> Developer Advocate @ Google Cloud Platform
>>>
>>> Blog: http://glaforge.appspot.com/
>>> Twitter: @glaforge <http://twitter.com/glaforge>
>>>
>>
Re: [DISCUSS] Proposed new optional module: groovy-contracts
Posted by Remko Popma <re...@gmail.com>.
Do we need a ICLA contributor agreement
<https://www.apache.org/licenses/contributor-agreements.html>?
On Mon, Aug 3, 2020 at 9:13 PM Paul King <pa...@asert.com.au> wrote:
> I am inclined to do a fresh start since as others have pointed out we do
> have the old repo. The old code is 3-clause BSD license but this
> contribution is being made under Apache license. Also, the code was
> refactored somewhat to be more consistent with the current code base
> styling and tweaked to work better with Groovy 3 and CompileStatic.
>
> Cheers, Paul.
>
> On Mon, Aug 3, 2020 at 10:01 PM Guillaume Laforge <gl...@gmail.com>
> wrote:
>
>> Agreed, but 1) it's definitely not the same size of project (only 300
>> commits for GContracts), and 2) the history is not lost since it stays in
>> the old project (even if it's less convenient to have to dig in another
>> location). Now that said, perhaps some of our ASF INFRA admins have some
>> super git abilities and know how to import some external sources with their
>> history?
>>
>> On Mon, Aug 3, 2020 at 12:26 PM Jochen Theodorou <bl...@gmx.org>
>> wrote:
>>
>>> On 03.08.20 11:50, Guillaume Laforge wrote:
>>> [...]
>>> > And honestly, it's pretty rare that we have to dig in anyway.
>>>
>>> that could be true in case of gcontracts.
>>> For groovy-core it certainly is not true. Especially if the code part I
>>> am looking at is unfamiliar it is very important to get why some things
>>> are how they are. That is also why it was so important to have all the
>>> old codehaus issues in apache.
>>>
>>> bye Jochen
>>>
>>>
>>
>> --
>> Guillaume Laforge
>> Apache Groovy committer
>> Developer Advocate @ Google Cloud Platform
>>
>> Blog: http://glaforge.appspot.com/
>> Twitter: @glaforge <http://twitter.com/glaforge>
>>
>
Re: [DISCUSS] Proposed new optional module: groovy-contracts
Posted by Marcin Zajączkowski <ms...@wp.pl>.
On 2020-08-03 14:12, Paul King wrote:
> I am inclined to do a fresh start since as others have pointed out we do
> have the old repo. The old code is 3-clause BSD license but this
> contribution is being made under Apache license. Also, the code was
> refactored somewhat to be more consistent with the current code base
> styling and tweaked to work better with Groovy 3 and CompileStatic.
That's sounds sensible for me to keep it with just one commit.
Regarding Guillaume Laforge's comment:
> Now that said, perhaps some of our ASF INFRA admins have some
> super git abilities and know how to import some external sources with their
> history?
Having a similar issue in the future you can let me know. I've already
did that trick a few times with different projects that started in
separate repos and were merged later on into submodules of some other
project.
Marcin
> On Mon, Aug 3, 2020 at 10:01 PM Guillaume Laforge <gl...@gmail.com>
> wrote:
>
>> Agreed, but 1) it's definitely not the same size of project (only 300
>> commits for GContracts), and 2) the history is not lost since it stays in
>> the old project (even if it's less convenient to have to dig in another
>> location). Now that said, perhaps some of our ASF INFRA admins have some
>> super git abilities and know how to import some external sources with their
>> history?
>>
>> On Mon, Aug 3, 2020 at 12:26 PM Jochen Theodorou <bl...@gmx.org>
>> wrote:
>>
>>> On 03.08.20 11:50, Guillaume Laforge wrote:
>>> [...]
>>>> And honestly, it's pretty rare that we have to dig in anyway.
>>>
>>> that could be true in case of gcontracts.
>>> For groovy-core it certainly is not true. Especially if the code part I
>>> am looking at is unfamiliar it is very important to get why some things
>>> are how they are. That is also why it was so important to have all the
>>> old codehaus issues in apache.
>>>
>>> bye Jochen
>>>
>>>
>>
>> --
>> Guillaume Laforge
>> Apache Groovy committer
>> Developer Advocate @ Google Cloud Platform
>>
>> Blog: http://glaforge.appspot.com/
>> Twitter: @glaforge <http://twitter.com/glaforge>
>>
>
--
https://blog.solidsoft.pl/ - Working code is not enough
Re: [DISCUSS] Proposed new optional module: groovy-contracts
Posted by Paul King <pa...@asert.com.au>.
I am inclined to do a fresh start since as others have pointed out we do
have the old repo. The old code is 3-clause BSD license but this
contribution is being made under Apache license. Also, the code was
refactored somewhat to be more consistent with the current code base
styling and tweaked to work better with Groovy 3 and CompileStatic.
Cheers, Paul.
On Mon, Aug 3, 2020 at 10:01 PM Guillaume Laforge <gl...@gmail.com>
wrote:
> Agreed, but 1) it's definitely not the same size of project (only 300
> commits for GContracts), and 2) the history is not lost since it stays in
> the old project (even if it's less convenient to have to dig in another
> location). Now that said, perhaps some of our ASF INFRA admins have some
> super git abilities and know how to import some external sources with their
> history?
>
> On Mon, Aug 3, 2020 at 12:26 PM Jochen Theodorou <bl...@gmx.org>
> wrote:
>
>> On 03.08.20 11:50, Guillaume Laforge wrote:
>> [...]
>> > And honestly, it's pretty rare that we have to dig in anyway.
>>
>> that could be true in case of gcontracts.
>> For groovy-core it certainly is not true. Especially if the code part I
>> am looking at is unfamiliar it is very important to get why some things
>> are how they are. That is also why it was so important to have all the
>> old codehaus issues in apache.
>>
>> bye Jochen
>>
>>
>
> --
> Guillaume Laforge
> Apache Groovy committer
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Twitter: @glaforge <http://twitter.com/glaforge>
>
Re: [DISCUSS] Proposed new optional module: groovy-contracts
Posted by Guillaume Laforge <gl...@gmail.com>.
Agreed, but 1) it's definitely not the same size of project (only 300
commits for GContracts), and 2) the history is not lost since it stays in
the old project (even if it's less convenient to have to dig in another
location). Now that said, perhaps some of our ASF INFRA admins have some
super git abilities and know how to import some external sources with their
history?
On Mon, Aug 3, 2020 at 12:26 PM Jochen Theodorou <bl...@gmx.org> wrote:
> On 03.08.20 11:50, Guillaume Laforge wrote:
> [...]
> > And honestly, it's pretty rare that we have to dig in anyway.
>
> that could be true in case of gcontracts.
> For groovy-core it certainly is not true. Especially if the code part I
> am looking at is unfamiliar it is very important to get why some things
> are how they are. That is also why it was so important to have all the
> old codehaus issues in apache.
>
> bye Jochen
>
>
--
Guillaume Laforge
Apache Groovy committer
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Twitter: @glaforge <http://twitter.com/glaforge>
Re: [DISCUSS] Proposed new optional module: groovy-contracts
Posted by Jochen Theodorou <bl...@gmx.org>.
On 03.08.20 11:50, Guillaume Laforge wrote:
[...]
> And honestly, it's pretty rare that we have to dig in anyway.
that could be true in case of gcontracts.
For groovy-core it certainly is not true. Especially if the code part I
am looking at is unfamiliar it is very important to get why some things
are how they are. That is also why it was so important to have all the
old codehaus issues in apache.
bye Jochen
Re: [DISCUSS] Proposed new optional module: groovy-contracts
Posted by Guillaume Laforge <gl...@gmail.com>.
The original source tree remains anyway in its original place.
Perhaps we lose the lineation, but if ever we really really need to hunt
through the history, it's still there.
And honestly, it's pretty rare that we have to dig in anyway.
On Mon, Aug 3, 2020 at 10:47 AM Marcin Zajączkowski <ms...@wp.pl> wrote:
> On 2020-08-03 09:47, Jochen Theodorou wrote:
> > On 03.08.20 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.
> >
> > I think there are some regulations to follow from the ASF side. Since
> > you and Andre are the sole committers it should not be too difficult.
> > Best of course would be if Andre would be a Apache member, then we could
> > do this as simple code contribution
> >
> >> 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
> >
> > +1 except... would this loose the history? That would not be nice.
>
> I have no practical experience with gcontracts, but I agree that the
> history could be useful to track some further issue with the module.
>
> I wonder, how problematic the merge was? It is was mostly "change
> package" and "move" refactor, maybe it would be good to do the fetch of
> external repository of gcontracts as an another remote repo, then do the
> changes in a separate branch and merge that branch into master via PR
> (preserving the history)?
>
> Nevertheless, it still generates some extra work.
>
> Marcin
>
> --
> https://blog.solidsoft.pl/ - Working code is not enough
>
--
Guillaume Laforge
Apache Groovy committer
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Twitter: @glaforge <http://twitter.com/glaforge>
Re: [DISCUSS] Proposed new optional module: groovy-contracts
Posted by Marcin Zajączkowski <ms...@wp.pl>.
On 2020-08-03 09:47, Jochen Theodorou wrote:
> On 03.08.20 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.
>
> I think there are some regulations to follow from the ASF side. Since
> you and Andre are the sole committers it should not be too difficult.
> Best of course would be if Andre would be a Apache member, then we could
> do this as simple code contribution
>
>> 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
>
> +1 except... would this loose the history? That would not be nice.
I have no practical experience with gcontracts, but I agree that the
history could be useful to track some further issue with the module.
I wonder, how problematic the merge was? It is was mostly "change
package" and "move" refactor, maybe it would be good to do the fetch of
external repository of gcontracts as an another remote repo, then do the
changes in a separate branch and merge that branch into master via PR
(preserving the history)?
Nevertheless, it still generates some extra work.
Marcin
--
https://blog.solidsoft.pl/ - Working code is not enough
Re: [DISCUSS] Proposed new optional module: groovy-contracts
Posted by Jochen Theodorou <bl...@gmx.org>.
On 03.08.20 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.
I think there are some regulations to follow from the ASF side. Since
you and Andre are the sole committers it should not be too difficult.
Best of course would be if Andre would be a Apache member, then we could
do this as simple code contribution
> 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
+1 except... would this loose the history? That would not be nice.
bye Jochen
GContracts Overview
Posted by 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.
>
Re: [DISCUSS] Proposed new optional module: groovy-contracts
Posted by Guillaume Laforge <gl...@gmail.com>.
+1
Le lun. 3 août 2020 à 07:57, Paul King <pa...@asert.com.au> a écrit :
>
> 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.
>
>