Unnamed variables and match-all patterns

[Tagir Valeev]

Hello!

чт, 8 сент. 2022 г., 00:14 Brian Goetz <brian.goetz at oracle.com>:

>
> >
> > As a teacher, i vote for A, APIs should be documented, giving a good
> > name to a parameter is usually the first step.
> >
>
> I'm willing to consider starting with A, though I think we should admit
> that the most likely reaction if we do that is "you idiots got it wrong
> again, we waited 25 years for underscore, and you don't even let us do
> it in the most obvious places."  So I don't think "do A and never do
> anything about method parameters" is going to fly, though it is
> potentially a reasonable incremental step on the way there to get people
> used to unnamed things.
>

I'm not sure it's so critical. To me, the main source of frustration is the
necessity to think up a name that I won't use anyway. The second source is
the fact that the code becomes noticeably longer when it includes unused
names. Both problems are not so important for method parameters:

- If you override or implement method, any IDE just copies names from the
super-method for you, so you don't need to think.
- Method declaration is already quite verbose. It contains @Override
annotation, modifiers, types of all parameters and return type explicitly
spelled, all of them could be quite long. Probably other annotations,
throws and Javadoc. Saving few chars there would not help much. On the
other hand, declaration doesn't contain logic, so people rarely stare at it
trying to understand what's going on.

Another problem, namely polluting namespace with an unused name, stays, but
I believe it's not so important. It may be confusing if you want to reuse
the name of super-method parameter for another purpose, so occupying it by
default has its advantages.

That's said, I'm also for A. It's simple and well defined. It's in line
with lvti philosophy and will be already very helpful without adding
confusion and strange corner cases.

With best regards,
Tagir Valeev.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20220908/6420f4e8/attachment-0001.htm>