[VOTE] Requiring final keyword on every parameter and local variable

Our coding standard and our Design Decisions does NOT require using final on parameters and local variables. Please do NOT request that I add or keep final on parameters or local variables unless the community votes and decides that every parameter and local variable should require the final keywo

Re: [VOTE] Requiring final keyword on every parameter and local variable

+1 I am 100% for putting final everywhere it is possible to put it. Call this the "hard final" position. What I've been advocating for, intermittently, in PRs (for example, in PR #6310 ) is more of a "soft final" position which I ca

Re: [VOTE] Requiring final keyword on every parameter and local variable

+1 To Kirk’s approach. -1 To final everywhere. I support Kirk’s approach of adding final where there is benefit. If we want to go further, we can have intellij find all of them and change them if we want. Final is not always a developer’s explicit statement. Sometimes something becomes final af

[VOTE] Apache Geode 1.12.2.RC1

Hello Geode Dev Community, Geode’s support/1.12 has gathered a few more fixes since 1.12.1 was released two months ago. I’d like to propose another patch release. This is a release candidate for Apache Geode version 1.12.2.RC1. Thanks to all the community members for their contributions to this

Stats deprecations?

Hi, So I am making some stats changes that are pretty minor, but I was looking at the fact that we have a ton of deprecated stuff about incInt and getInt. Can we convert those to longs? This would mean changing storage and return types. Thanks, Mark

Re: [Suspected Spam] [VOTE] Apache Geode 1.12.2.RC1

+1 Confirmed that performance in multiple scenarios is on par with the previous 1.12 release. From: Owen Nichols Sent: Wednesday, April 14, 2021 3:38 PM To: dev@geode.apache.org Subject: [Suspected Spam] [VOTE] Apache Geode 1.12.2.RC1 Hello Geode Dev Community,

Re: Stats deprecations?

The deprecated int methods are there for API compatibility but are backed by the LongAdder that backs the long stats. If you find any stats still using the int methods feel free to update them to use the long methods. See https://issues.apache.org/jira/browse/GEODE-6424 and related tickets. -J

Re: Stats deprecations?

Looks like those methods were deprecated in GEODE-6850. If I'm reading that correctly, there is no reason not to change the calls to incLong, getLong, etc. I'd say go for it. -Dan From: Mark Hanson Sent: Wednesday, April 14, 2021 3:43 PM To: dev@geode.apache.org

Re: Stats deprecations?

The one gotcha which I am totally fine with is that the actual calls like get will return long rather than int. Is that going to break anything? On 4/14/21, 4:10 PM, "Dan Smith" wrote: Looks like those methods were deprecated in GEODE-6850. If I'm reading that correctly, there is no reas

Re: [VOTE] Requiring final keyword on every parameter and local variable

Just to confirm for myself... final doesn't necessarily make object immutable.. the reference is immutable but if it refers to say a list, the list is still mutable. So if I see a final keyword, I should only expect the reference not to change, but it won't guarantee that the object isn't chang

Re: [VOTE] Requiring final keyword on every parameter and local variable

Does this really "add noise" instead of "add clarity and precision" ? -Robert On 4/14/21, 4:25 PM, "Jason Huynh" wrote: Just to confirm for myself... final doesn't necessarily make object immutable.. the reference is immutable but if it refers to say a list, the list is still mutable.

Re: [VOTE] Requiring final keyword on every parameter and local variable

If a method is longer than a handful of lines and I go in to refactor it I am going to start by making every variable I find final. Then I am going to figure out how to keep them final. By doing so you naturally produce smaller functional methods that are usually independently unit testable. Sma

Re: [VOTE] Requiring final keyword on every parameter and local variable

Yeah, understood just an opinion about noise __ The clarity and precision part I'm debating a bit but I also don't do code review or work in the actual code base as much as before so I'll go with a -0 vote for me and let everyone else that does see the code more often decide __ On 4/14/21, 4

Re: Stats deprecations?

It might break something but it should not be too bad. Internal product features are not supposed to read stat values and make decisions based on them because geode allows stat storage to be disabled. Also all these callers of the deprecated methods will be internal. So most of the code that cal

Re: [VOTE] Requiring final keyword on every parameter and local variable

-1 for requiring final for all method parameters. While I have nothing against using final here, I don’t think it’s worth mandating and would be better left up to the individual and the specific circumstance. On Apr 14, 2021, at 4:33 PM, Jason Huynh mailto:jhu...@vmware.com>> wrote: Yeah, unde

Re: [VOTE] Requiring final keyword on every parameter and local variable

"+1" to ENCOURAGING developers to make "final" a requirement for method arguments. "-1" to making it a hard rule. If we want to enforce this rule on the basis of readability or performance, I fear that we might be beating the wrong horse here for the wrong reasons!! Short reasoning: If we rea

Re: [VOTE] Requiring final keyword on every parameter and local variable

> On Apr 14, 2021, at 7:46 PM, Udo Kohlmeyer wrote: > @Jake the idea of smaller methods is great and we should ALWAYS strive for > that. But that argument is completely irrelevant in this discussion. As > making method arguments final does not naturally guide a developer to > creating smaller