lambda expression parameters

Talden talden at gmail.com
Wed Dec 19 14:11:05 PST 2012


On Thu, Dec 20, 2012 at 10:43 AM, Howard Lovatt <howard.lovatt at gmail.com>wrote:

> First a disclosure. I personally always declare everything final by
> default, it suits my 'immutable' programming style.
>

That is the team guidance here as well.  Omitting final is an indicator you
intend to treat it as a variable.

If Java were done over from scratch it would be tempting to flip it on it's
head an make everything implicitly final unless marked as a 'var'.  Heck
it'd be tempting to treat classes as implicitly final to promote
composition over inheritance too - though 'var' would be an odd choice of
word there and interfaces would probably want to continue to be extendable
making it inconsistent (not good for implicit rules).

It would be a shame to not be able to declare final without retaining the
implicit typing.

Rémi suggested that the best solution is a VCS pre-commit hook which is a
good solution but not my preference.  Creating a blocker for commit that
could significantly delay the timeliness of the commit seems less
productive than just doing static analysis performed as part of a CI build
plan. Builds on release-branches can be more stringent and consider more of
the warnings as errors to catch any aberrations that weren't caught in
review, on subsequent fix commits or marked as intentional.  Providing the
ability to get the list of warnings as part of locally building it is a
good idea so that developers can self-audit just as they should for some if
not all of the unit-testing suite too (which again should be a standard
part of the CI build plan).

--
Aaron Scott-Boddendijk


More information about the lambda-dev mailing list