groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Winnebeck, Jason" <Jason.Winneb...@windstream.com>
Subject RE: precedence rules for power operator vs -, +, ++, --
Date Mon, 08 Jun 2015 17:01:51 GMT
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:cedric.champeau@gmail.com]
Sent: Monday, June 08, 2015 12:02 PM
To: users@groovy.incubator.apache.org
Subject: Re: precedence rules for power operator vs -, +, ++, --



2015-06-08 15:02 GMT+02:00 Winnebeck, Jason <Jason.Winnebeck@windstream.com<mailto:Jason.Winnebeck@windstream.com>>:
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.
Mime
View raw message