[lambda-leftovers] Underscore parameter for abstract/native methods

[Remi Forax]

I am not confortable with any solution but D, lambdas are just anonymous methods.

With lambda leftover, we are bridging the gap between methods and lambdas by saying that lambdas have the same scope rules as methods, making lambdas less specific in term of feature. 

So restricting underscore to lambda only goes is the wrong direction, because it artificially re-create a gap between methods and lambdas in term of feature.

regards,
Rémi


On July 14, 2017 4:38:08 PM GMT+02:00, Vicente Romero <vicente.romero at oracle.com> wrote:
>
>
>On 07/10/2017 06:47 AM, Tagir Valeev wrote:
>> Hello!
>>
>> I see that A was selected and currenty I support it. Just a short
>opinion
>> against C for the record. There are many cases when method does not
>> override another one, but has to declare some parameters. Examples:
>> - public static void main: using main(String[] _) would indicate that
>> command line parameters are not used.
>> - name parameter in BootstrapMethodFactory: often it's unnecessary
>> - some annotation-based APIs when method annotation directs a
>framework to
>> call this method reflectively with specific parameters (but some of
>them
>> are not used actually)
>> - a lambda with unused parameter which was converted to a method for
>> convenient use as a method reference
>>
>> So covering traditional inheritance, but not covering these cases
>looks
>> arbitrary indeed.
>
>right, good point and thanks for the feedback. We preferred to move to
>a 
>conservative mode and keep this feature small which was the first
>intention.
>
>>
>> With best regards,
>> Tagir Valeev.
>
>Vicente
>
>>
>> On Sat, Jul 1, 2017 at 12:38 AM, Brian Goetz <brian.goetz at oracle.com>
>wrote:
>>
>>> So, a fair question is whether _ should be supported for methods at
>all,
>>> because (in many cases) method parameters are both declaration and
>>> implementation.  This feature started out for lambdas (whose
>parameters are
>>> pure implementation), and then got extended to catch formals (also
>pure
>>> implementation) and method parameters (not pure implementation.) 
>And once
>>> we bring in methods, it raises tooling questions like "what about
>Javadoc."
>>> So maybe the last step was the problem.
>>>
>>> Here's a menu of defensible options here:
>>>
>>> A. Don't allow _ for method or constructor parameters.
>>>
>>> B. Only allow _ for method parameters in *anonymous* classes. This
>has the
>>> advantage that it makes it easier to freely refactor lambdas to/from
>anon
>>> classes.
>>>
>>> C. The option I proposed the other day -- only allow _ as a method
>>> parameter name for concrete class methods that are known to be an
>@Override
>>> of some other method.  This excludes all interface and abstract
>methods,
>>> constructors, and "initial declarations" of methods in base classes.
>>>
>>> D. Allow it in all methods.
>>>
>>>
>>> Now that this has been pointed out, I'm pretty down on D.  C is
>>> defensible, but likely will feel arbitrary.  B does has a nice
>symmetry to
>>> it, but it means it drags tooling support (Javadoc) into the
>feature.  And
>>> A avoids the problem entirely.  (Though, like with LVTI, people will
>>> inevitably ask "but what about private methods?  And they'd get the
>same
>>> answer, regarding source compatibility of modifier changes.)
>>>
>>> Leaning towards A....
>>>
>>>
>>> On 6/25/2017 6:51 AM, Tagir Valeev wrote:
>>>
>>>> Hello!
>>>>
>>>> Currently in lambda-leftovers underscore is allowed as a parameter
>name
>>>> for
>>>> abstract methods. This looks dubious as normally underscore means
>that
>>>> parameter is not used in the corresponding method/lambda/catch
>body, but
>>>> there's no actual body and no parameter is actually used anyways
>(but
>>>> could
>>>> be used in abstract method implementations). I think, allowing
>underscores
>>>> for interface methods may encorage bad practices of defining
>interfaces
>>>> without readable parameter names:
>>>>
>>>> interface X {
>>>>     void doSomething(int _, long _, String _);
>>>> }
>>>>
>>>> Should not this be disabled?
>>>>
>>>> It's even worse for native methods, because underscore assumes that
>>>> parameter is not used, but it does not limit the corresponding
>native
>>>> implementation from using it.
>>>>
>>>> With best regards,
>>>> Tagir Valeev.
>>>>
>>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.