Yes, given that Jochen saw precedence in Python and Lua for power operator to have higher precedence than unary, and it has precedence in written math, and it’s already working that way in Groovy now, I don’t think it should ever change, but that’s just my opinion.
As for the breaking changes, I’ve mentioned them on the list in the past. I’m not sure I’ve done any major Groovy version upgrade without at least one disappointing breaking change. I’m not talking about purposeful ones (except for the change that had to be made to sort for Java 8 compatibility), but regressions and unintended changes. The most recent one was the change where if a class has “isX” and “getX”, it used to call getX but then it started calling isX (or maybe it was the other way around). I think this was upgrade from 2.3 to 2.4 Then upgrade from 2.2 to 2.3 and I run into closures in children classes can’t call static methods in their parents: https://issues.apache.org/jira/browse/GROOVY-6883. In the earlier 2.x days, I believe I ran into issues where code that used to compile with @CompileStatic didn’t after some type checker changes, but the static compiler is a lot more stable now, although I still run into issues on a daily basis: one is given interface X and interface Y extends X, you cannot import static Y and use the constants of X (as you can in Java, and as IntelliJ can auto-import for you) -- https://issues.apache.org/jira/browse/GROOVY-7460. The second is a case in nested closures where there is a delegate and I’m accessing a property, the code resolves properly in IntelliJ but the generated bytecode issues a call to the “this” (parent) class instead so I get NoSuchMethodError, and when this happens I replace the .prop with .getProp(). For that one I’ve not been able to reproduce in isolation yet, so no JIRA but it happens to me and my teammates a bit. In these cases it’s bugs but it also contributes to the “every version of Groovy is different.” So I have to think about issues like https://issues.apache.org/jira/browse/GROOVY-6891 where if I go back before 2.4 I have to remember that I can’t rely on overloaded setters in compile static, so it’s a sort of “mental” breaking change as I have to keep these in mind. I love Groovy, a lot, and by no means do I want to downplay the effort of the developers on it (and I know how much I’m paying for it), but while it is by far my favorite development environment for the past few years I have to admit to people that I run into issues a lot on just fundamental things and hold back on a blanket endorsement. Jason From: Cédric Champeau [mailto:[email protected]] Sent: Monday, June 08, 2015 12:02 PM To: [email protected] Subject: Re: precedence rules for power operator vs -, +, ++, -- 2015-06-08 15:02 GMT+02:00 Winnebeck, Jason <[email protected]<mailto:[email protected]>>: If this isn't a clear cut fix then you might want consider leaving it as it is for backwards compatibility. Groovy already has enough issues with breaking changes. I agree that we should avoid breaking changes on this on a dot release. It's not really a bugfix but a semantic change. That said, can you elaborate on "Groovy has enough issues with breaking changes"? In general we do a pretty good job I think to preserve compatibility. What problems did you face? Were those problems documented as breaking changes? If not, were they simply bugs? ---------------------------------------------------------------------- This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments.
