lambda expression parameters

[Remi Forax]

On 12/19/2012 05:13 PM, Venkat Subramaniam wrote:
> Over the past couple of years I have been caught at least twice by bugs where I wasted significant time.
> In both cases, the programmer had modified the parameter of the method and in the process
> introduced the bugs. I have since started marking my method parameters final (call me paranoid).
> I find it really odd that anyone would want to modify the parameters, but I have seen it happen.
> One thing I really appreciate in languages that support functional style (hybrid or not) is the treatment
> of parameters as final by default. I fully understand this can't be done for Java for regular methods.
> I sincerely thing this is a good opportunity for such treatment for parameters to lambda expressions.
> I hope this is given a good consideration among the key decision makers. Thank you.

The best way to enforce a coding style is to install a pre-commit hook 
on your VCS and do all the static analysis you want.

also, I propose that all if, for and while in a lambda requires curly 
braces because my students with a Python background think that indenting 
the code is enough.

>
> Venkat

Rémi

>
> On Dec 19, 2012, at 9:04 AM, Ricky Clarkson <ricky.clarkson at gmail.com> wrote:
>
>> I'd just like to raise one potential case for making it implicitly final:
>>
>> Iterable<Boolean> list = someNumbers.map(x -> x = 5);
>>
>> (If it really returns a Stream, Streamable, CanBeStreamed or
>> NotTonightDearImBusyStreaming, please give me some leeway.)
>>
>> The programmer is left wondering why the compiler says that map returns an
>> Iterable<Integer> instead of an Iterable<Boolean>, and it's all because he
>> used = instead of ==.  The programmer then wonders why Java didn't just
>> give him a compile error when he assigned to the parameter, after all
>> assigning to the parameter there is basically a no-op.
>>
>>
>> On Wed, Dec 19, 2012 at 1:44 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
>>
>>> On Tue, Dec 18, 2012 at 8:15 PM, Dan Smith <daniel.smith at oracle.com>
>>> wrote:
>>>> On Dec 18, 2012, at 5:43 PM, David Holmes <David.Holmes at oracle.com>
>>> wrote:
>>>>> I don't grok the problem. If the parameter is not modified then it is
>>>>> effectively final. Making parameters final is then only an
>>>>> error-detection mechanism, and I don't see that is warranted in lambda
>>>>> expressions. So I don't see "final by default" as warranted.
>>>>>
>>>>> Having to add back the inferred type to enable final to be added doesn't
>>>>> seem like a large burden.
>>>> Yeah, I think I agree with David.  The times when it seems most useful
>>> to say "this parameter is final and I definitely don't want anyone changing
>>> it" are when you've got a large lambda body, and then it's really not so
>>> painful to give your parameters full declarations ('final String s').
>>>> It's worth noting that 'final' parameters and local variables didn't
>>> exist in the original language and were only added to support the "captured
>>> variables must be final" rule when anonymous/local classes were added.  If
>>> "effectively final" were an option back then (don't know if it's something
>>> they thought about or not), I would bet we still wouldn't have 'final'
>>> parameters and local variables.  They're really a lot less useful than
>>> 'final' fields -- because all interaction is in a single thread and within
>>> a single block of code.
>>>
>>> Agreed, although most method parameters and many local variables are
>>> conceptually final, people don't bother to mark them final.
>>>
>>> Making method parameters implicitly final is inconsistent with
>>> existing practices; the benefit is dubious:
>>>
>>> If a programmer assigns a new value to a method parameter, and later
>>> reads it, it is very likely intentional, there's no need for alarm
>>> here.
>>>
>>> If a programmer assigns a new value to a method parameter, and never
>>> reads it, it is probably a mistake; fortunately IDEs will raise a
>>> warning for it.
>>>
>>> Zhong Yu
>>>
>>>>> On the other hand can't the compiler accept
>>>>> parameter modifiers even if it infers the type?
>>>> No, there are two syntax options: list of identifiers, or full method
>>> parameter list.  Less complex that way.
>>>> —Dan
>>>>
>>>
>