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
