groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: About the "implies" operator(GROOVY-2576)
Date Wed, 25 Jan 2017 19:20:14 GMT
On 25.01.2017 17:50, Daniel Sun wrote:
> Hi all,
>
>        The "implies" operator "=>" was suggested many years ago, here is the
> replated JIRA issue( GROOVY-2576
> <https://issues.apache.org/jira/browse/GROOVY-2576>  ) .
>
>        Do you want it for Groovy 3? (+1: yes; -1: no; 0: not bad)
>
>        BTW, recently I have been going through the issues related to the old
> parser, many issues existing for many years do not exist in the new parser
> Parrot :)

If we do this (and I say +1) we should clear some things:
1) what does a=>b=>c mean, since (a=>b)=>c is not the same as a=>(b=>c)
2) use groovy truth and when to apply it? If we map a=>b to !a||b, then 
it will use Groovy truth on a and b, but if we map to an implies method 
it will get a and b, use groovy truth on them or not and we then maybe 
use groovy truth on the result. I personally would be for not using 
groovy truth here, thus make it more in line with | and &.
3) if a=>b is mapped to !a||b we will evaluate a, negate it, and 
depending on the result maybe never evaluate b. As long as a and b are 
free of side effects, that does not play an extremely important role, 
but if we map it to a method a and b will be evaluated always. If we 
would say it is more like !a|b, which would also require both being 
evaluated, then there is still the fact that !a ensures we call here 
always the boolean or function, never one defined by an arbitrary a
4) instead of using !a, which converts a to a boolean and negates it, we 
can also use ~a, which is a binary negate also working on booleans, but 
not converting a to a boolean if it is no boolean. Here we have to 
especially think about ~a|b calling "or" on a Pattern if a is a String. 
Also not many things besides boolean and numbers really support 
something useful of the binary negate.

I mention those points so we can make a proper specification for the 
behaviour of this operator ;)

bye Jochen

Mime
View raw message