Bitten by the lambda parameter name

[Remi Forax]

On 07/17/2013 01:25 AM, maurizio cimadamore wrote:
> On 16-Jul-13 11:59 PM, Remi Forax wrote:
>> On 07/17/2013 12:40 AM, maurizio cimadamore wrote:
>>> On 16-Jul-13 11:17 PM, Dan Smith wrote:
>>>> >   StringBuilder builder = createText(StringBuilder.class, builder 
>>>> -> builder.append("name"));
>>> What is this meant to replace exactly? It's a shorthand for:
>>>
>>> StringBuilder builder = new StringBuilder();
>>> builder.append("name");
>>>
>>> ?
>>>
>>> Maurizio
>>
>> Again, I'm not sure why this is interesting to know exactly what the 
>> code does,
>> Anyway, the code of createText allows you to create a mutable object 
>> by reflection, to initialize it and when you get the result,
>> you have the guarantee that you can never see the object half 
>> initialized.
> I'm asking about the code, because I think that if we are forcing 
> people to write code like that there might be a problem other than the 
> scope issue.
> Having two variables so close with the same name is confusing - no 
> matter how the language will pan out in the end. YOu seem to imply 
> that using the same name is justified by the fact that the two objects 
> are really the same - but I'm less sure that many people will be able 
> to read your code and immediately grasp as to why the two variables 
> are named in the same way. I think a good API should minimize 
> occurrences of that for the users sake.

First, you seem to think that users will use only one API at the same 
time, but we all know that power come from the way you interweave 
libraries calls. About reusing variable name, in my opinion, it's not 
dissimilar to asking if the constructor is allowed to re-use field name 
or not.
Like in this code:
   class Point {
     int x, y;
     Point(int x, int y) {
       ...
     }
   }

In my opinion, it's a matter of taste, but what is sure is that 
forbidding to be able to write the code above is a bad idea.
So disabling the hiding of local variable by lambda parameter should be 
an IDE warning and not an compiler error.

>
> Maurizio

Rémi