GROOVY-9017 DGM methods

[tomikoskinen]

https://issues.apache.org/jira/browse/GROOVY-9017

Instead of making keywords for and, or and not, we added a Boolean not() method in DefaultGroovyMethods to get most of what was wanted. DGM already had a or() and and() methods.

This PR was made by: @tomikoskinen @jonspe @Justsofun @rhanlol

[eric-milles]

Are there any test cases that use and, or, xor and now not as extension methods? I'd be interested to see if the style you seek is indeed supported. Is there any concern about having "not" as a completion for pretty much any variable/property expression? I don't think we have a way to say that the "self" parameter is intended for the "implicit-this" case only.

Otherwise, the form of the change looks proper to me.

[paulk-asert]

I am inclined to close this. While I think the goal of having the English equivalents is a nice idea and handy for certain DSL scenarios, I think there are enough problems to outweigh having that built-in to the language.

Firstly, for code as shown in the issue, e.g. "if(validated or administrator){", the conditional expression will normally be parsed as the following command chain "validated(or).administrator". Similarly for "and". You would need to write "validated.or(administrator)" if you didn't like "validated || administrator" or "validated | administrator". So, you would need a little bit of DSL processing code with property missing or similar to actually make "and" and "or" work as described.

Secondly, there might be confusion in that "not" isn't our mechanism for operator overloading "!", whereas "or" and "and" are our mechanism for overloading "&" and "|". We kind of treat "&&", "||" and "!" specially. We use "asBoolean" to override Groovy truth and then "&&", "||" and "!" just work with the results from Groovy truth. There is nothing stopping folks from defining their own "not" method, and they can tailor the definition to their DSL scenario.