Does this really "add noise" instead of "add clarity and precision" ?
-Robert
On 4/14/21, 4:25 PM, "Jason Huynh" <jhu...@vmware.com> 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.
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 changing.
I'm a -1 on forcing the issue because I believe we currently have too many
"edge cases" where we can't stick a final on. So we end up adding complexity
in reading without the benefit guaranteeing anything... I'd dislike seeing
something like this make it partway and then get abandoned...
Also are we only discussing local variables, class variables and method
parameters? Ignoring final on methods and classes?
On 4/14/21, 2:18 PM, "Mark Hanson" <hans...@vmware.com> wrote:
+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 after the fact.
If we manually touch any code, I would much rather we deal with the use
of raw types than have final everywhere. This strikes me as a minor issue
compared to the rampant use of raw types.
E.g.
RegionFactory regionFactory =
getCache().createRegionFactory(RegionShortcut.PARTITION_REDUNDANT);
Region region = regionFactory.create (“testRegion”);
Region.put(int, String);`
Thanks,
Mark
From: Bill Burcham <bill.burc...@gmail.com>
Date: Wednesday, April 14, 2021 at 1:53 PM
To: dev@geode.apache.org <dev@geode.apache.org>
Subject: 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
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F6310%23discussion_r612710322&data=04%7C01%7Crhoughton%40vmware.com%7C07622d5b63e947f8ae8a08d8ff9c9761%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637540395310059043%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=cPBS4vgpCEBxmLaV%2B8hlkx5xONw6R9bln32riw42d%2Bg%3D&reserved=0>)
is
more of a "soft final" position which I can formulate as:
The final keyword is valuable everywhere. When we encounter it in code,
we
assume that the author put it there intentionally to communicate that
the
variable will not change. Since the code compiled before our change, we
know that the variable does not change (the compiler has proven it!)
When
modifying code, we do not remove the final keyword unless we have to (to
get the code to compile).
So that's the "soft final" position. But I'm all for Kirk's "hard
final" if
others agree. I just don't see any downside—only upside on this one.
The final keyword is a vehicle, like types, for programmers to
communicate
their intentions. In both cases, the compiler can provide valuable
validation. There is, unfortunately, some visual noise entailed (lots of
occurrences of "final" in the code). But this makes non-final (mutable)
variables much more apparent. Since they are (or should be) in the
minority, this is an aid to maintainers. This becomes apparent in
longer,
more complex methods.
On Wed, Apr 14, 2021 at 12:56 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
>
