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 Thu, 26 Jan 2017 11:03:12 GMT


On 26.01.2017 11:05, Remi Forax wrote:
[...]
> Moreover as Jochen said , implies is a lazy operator, like && and ||, so
> the operator should be more =>=> than => (i.e !a || b vs !a | b).

I tried to say that if we see it as !a || b, we have a lazy operator and 
if we map it to a method call, then we cannot have this. The big 
difference is that || is a built-in operator working on booleans, 
nothing else. To ensure a and b are booleans we are using Groovy Truth 
on them. a|b is mapped to a method, thus a and b will have eager 
evaluation. If Groovy Truth is applied to them or not depends on the 
methods implementation.

If you now have Java-code in the form of let's say

foo!=null && bar.x

then you can rewrite it to foo!=null => !bar.x, then you would get a 
NPE, if you mapped it to a implies method, that takes foo!=null and !bar.x.

> Also if there is a method 'implies' as there is a method 'plus', implies
> should take a closure and not the result of an expression.
> At that point, the question is whenever or not to also implement && and
> || as method and has a general 'lift' syntax when declaring a method, it
> will make simple macro far easier to write at the expense of more magic.

I think that would have quite the negative impact on performance for ||. 
At least if the operands are booleans

bye Jochen

Mime
View raw message