Sorry Bruce, that's my lack of Apache finesse. I know you might expect me to remember it but I don't start discussions or votes often enough to remember. I'll be sure to read up on this process before starting any threads in the future.
On Thu, Apr 15, 2021 at 7:32 AM Bruce Schuchardt <bru...@vmware.com> wrote: > I agree with Udo. Also, this shouldn't be a VOTE without discussion and I > don't see a DISCUSS thread. > > On 4/14/21, 7:46 PM, "Udo Kohlmeyer" <u...@vmware.com> wrote: > > "+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 really want to effect real lasting change, is to adopt > principles that Rust (object owners) and Kotlin (immutable collections) > make core to the language. Immutable POJOs and possibly an extension for > collections to make intent of immutability clear would be far more > effective. As code reviewers would be able to look at a method definition > and instantly know what arguments are mutable. > > Adding "final" on fields, methods and classes has a far greater effect > than that of method arguments. If we intent to enforce it based on > readability, then we should really consider applying different approaches > (as stated in the paragraph above) that can be used with far greater > effectiveness. > > Longer reasoning: > > I think all arguments relating to "indicating authors intent" or > "variable does not change" are great, but in reality we as developers > should always assume that this was the intent. I think if we really want to > improve our code base, let's opt for IMMUTABLE data objects. The "final" > keyword has no benefit if you pass around POJOs (including Collections). As > long as you don't change the instance reference, the "final" keyword has > absolutely no effect. It does not mean that you cannot change every field > internal of the POJO. The "final" keyword is only effective against the > re-assignment of that variable/argument within a method. But a better > practice is to avoid the re-assignment of any variable/argument in the > first place. > > Kotlin has a great language (one of many) that method/function > arguments are naturally final and this behavior cannot be changed. In > addition there is a the feature that the collections are immutable and as a > developer you have to be explicit if you want a collection to be mutable, > by defining the collection as a "Mutable*" i.e MutableMap, MutableSet, > MutableList > > @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 methods. Nor does a smaller method mean it can/will be > jitted. Too many factors (to discuss here) are part of that decision, also > it is not relevant in this discussion. But more on that topic read THIS. > > --Udo > > On 4/15/21, 9:29 AM, "Jacob Barrett" <jabarr...@vmware.com> wrote: > > 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. Smaller methods can get jitted. Smaller methods can take less > time to reach a safe point (see time to safe point issues in Java). > > For this reason I strongly prefer on final everywhere and if you > think you need a variable to not be final you should use that as an > indicator to refractor your code. > > So, +1 for me for final everywhere. > > Also, please stop declaring variables miles away from their use. > > > On Apr 14, 2021, at 12:55 PM, Kirk Lund <kl...@apache.org> > wrote: > > > > 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 keyword. I coded this > way in the > > past and I found that it resulted in noisy code with no benefit. > We can > > argue about using this keyword all you want but the fact is I'm > against it, > > and I will not embrace it unless this community decides that we > need to use > > it. > > > > Using final on instance or class fields does have a concurrency > benefit and > > I support that only. > > > > If you want to add final to every single parameter and local var > in the > > Geode codebase, then now is your chance to vote on it. Please > vote. > > > > Thanks, > > Kirk > > > >
