[
https://issues.apache.org/jira/browse/NETBEANS-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niklas Matthies updated NETBEANS-3001:
--------------------------------------
Description:
Example:
{{import java.nio.file.Path;}}
...
{{Path path = ...;}}
{{if (isRegularFile(path)) ...}}
{{if (exists(path, null)) ...}}
Observed behavior:
Alt+Return on {{exists}} offers static import of
{{java.nio.file.Files.exists}}, but Alt+Return on {{isRegularFile}} does not
offer static import of {{java.nio.file.Files.isRegularFile}}. This is
apparently because {{isRegularFile}} (like {{exists}}) has a second parameter
which is a vararg parameter.
Expected behavior:
Alt+Return on {{isRegularFile}} should offer static import of
{{java.nio.file.Files.isRegularFile}}.
Further discussion:
I would actually go so far to suggest that offering of static import shouldn't
require the number and type of arguments to match at all, for the following
reasons:
* Most importantly: This would allow to have automatic argument fill-in applied
after selecting the desired static method from the popup. Currently, to get
automatic argument fill-in in combination with static imports one has only the
choice between (a) checking "Prefer Static Imports" in Options > Editor >
Formatting > Java > Imports and use Ctrl+Space, which has the serious downside
that you can't choose dependent on context whether you want a static import or
not (half of the time it's better for clarity to not use static import), or (b)
using the three-step process of \(i) using Ctrl+Space to get automatic argument
fill-in on {{someMethod}} (and a regular import of {{SomeClass}}) without
static import, then (ii) using Alt+Return to get the static import, and (iii)
using Fix Imports to get rid of the non-static import of {{SomeClass}}
introduced by step (i). It would be much more useful to always have the choice
between (1) using step (i) if no static import is desired, and (2) using
Alt+Return on {{someMethod}} and getting automatic argument fill-in as well as
a static import for the selected method.
* Static imports don't distinguish between different overloads (you always get
all overloads), so arguably it makes less sense to require the code to already
match a specific overload.
* There isn't usually a large number of static methods with the same name, so
listing them all (with all overloads) in the popup shouldn't generally be a
problem.
was:
Example:
{{import java.nio.file.Path;}}
...
{{Path path = ...;}}
{{if (isRegularFile(path)) ...}}
{{if (exists(path, null)) ...}}
Observed behavior:
Alt+Return on {{exists}} offers static import of
{{java.nio.file.Files.exists}}, but Alt+Return on {{isRegularFile}} does not
offer static import of {{java.nio.file.Files.isRegularFile}}. This is
apparently because {{isRegularFile}} (like {{exists}}) has a second parameter
which is a vararg parameter.
Expected behavior:
Alt+Return on {{isRegularFile}} should offer static import of
{{java.nio.file.Files.isRegularFile}}.
Further discussion:
I would actually go so far to suggest that offering of static import shouldn't
require the number and type of arguments to match at all, for the following
reasons:
* Most importantly: This would allow to have automatic argument fill-in applied
after selecting the desired static method from the popup. Currently, to get
automatic argument fill-in in combination with static imports one has only the
choice between (a) checking "Prefer Static Imports" in Options > Editor >
Formatting > Java > Imports and use Ctrl+Space, which has the serious downside
that you can't choose dependent on context whether you want a static import or
not (half of the time it's better for clarity to not use static import), or (b)
using the three-step process of (i) using Ctrl+Space to get automatic argument
fill-in on {{someMethod}} (and a regular import of {{SomeClass}}) without
static import, then (ii) using Alt+Return to get the static import, and (iii)
using Fix Imports to get rid of the non-static import of {{SomeClass}}
introduced by step (i). It would be much more useful to always have the choice
between (1) using step (i) if no static import is desired, and (2) using
Alt+Return on {{someMethod}} and getting automatic argument fill-in as well as
a static import for the selected method.
* Static imports don't distinguish between different overloads (you always get
all overloads), so arguably it makes less sense to require the code to already
match a specific overload.
* There isn't usually a large number of static methods with the same name, so
listing them all (with all overloads) in the popup shouldn't generally be a
problem.
> Code completion for static imports doesn't handle varargs
> ---------------------------------------------------------
>
> Key: NETBEANS-3001
> URL: https://issues.apache.org/jira/browse/NETBEANS-3001
> Project: NetBeans
> Issue Type: Bug
> Components: java - Editor
> Affects Versions: 11.1
> Reporter: Niklas Matthies
> Priority: Major
>
> Example:
> {{import java.nio.file.Path;}}
> ...
> {{Path path = ...;}}
> {{if (isRegularFile(path)) ...}}
> {{if (exists(path, null)) ...}}
> Observed behavior:
> Alt+Return on {{exists}} offers static import of
> {{java.nio.file.Files.exists}}, but Alt+Return on {{isRegularFile}} does not
> offer static import of {{java.nio.file.Files.isRegularFile}}. This is
> apparently because {{isRegularFile}} (like {{exists}}) has a second parameter
> which is a vararg parameter.
> Expected behavior:
> Alt+Return on {{isRegularFile}} should offer static import of
> {{java.nio.file.Files.isRegularFile}}.
> Further discussion:
> I would actually go so far to suggest that offering of static import
> shouldn't require the number and type of arguments to match at all, for the
> following reasons:
> * Most importantly: This would allow to have automatic argument fill-in
> applied after selecting the desired static method from the popup. Currently,
> to get automatic argument fill-in in combination with static imports one has
> only the choice between (a) checking "Prefer Static Imports" in Options >
> Editor > Formatting > Java > Imports and use Ctrl+Space, which has the
> serious downside that you can't choose dependent on context whether you want
> a static import or not (half of the time it's better for clarity to not use
> static import), or (b) using the three-step process of \(i) using Ctrl+Space
> to get automatic argument fill-in on {{someMethod}} (and a regular import of
> {{SomeClass}}) without static import, then (ii) using Alt+Return to get the
> static import, and (iii) using Fix Imports to get rid of the non-static
> import of {{SomeClass}} introduced by step (i). It would be much more useful
> to always have the choice between (1) using step (i) if no static import is
> desired, and (2) using Alt+Return on {{someMethod}} and getting automatic
> argument fill-in as well as a static import for the selected method.
> * Static imports don't distinguish between different overloads (you always
> get all overloads), so arguably it makes less sense to require the code to
> already match a specific overload.
> * There isn't usually a large number of static methods with the same name, so
> listing them all (with all overloads) in the popup shouldn't generally be a
> problem.
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
