This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | Automatic import of new classes from code completion | ||
|---|---|---|---|
| Product: | editor | Reporter: | khaipi <khaipi> |
| Component: | Completion & Templates | Assignee: | Dusan Balek <dbalek> |
| Status: | NEW --- | ||
| Severity: | blocker | CC: | markiewb |
| Priority: | P3 | ||
| Version: | 5.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | ENHANCEMENT | Exception Reporter: | |
|
Description
khaipi
2005-10-31 22:10:06 UTC
Perhaps the functionality of automatic imports should be optional so that those who prefer the older system can have it still. Necessary imports are already added when item from code completion is selected. Auto-importing has to solve the problem of reasonably inferring the intentions of the programmer- do they want to import a class or create a class or create an inner class? It's impossible to know for sure, but something like the following would go a long way to enhancing auto-import. Netbeans should auto-import when a class unambiguously matches one in packages which are 1) very common (java.* javax.* etc.). For example, I am guessing that most people use the libs in the JDK, even though there classes with the same names in say, trove. People using trove often times want it for ONE package or even a specific class. So an option would be to always auto-import from the JDK even if matching trove classes were found. satisfactory tweaking of this default behaviour might be achievable using 3 below . 2) OR listed explicitly by the developer on a configuration screen. 3) AND not on a developer-specified excludes list (say if I were creating my own swing widgets with the same names as the original swing widgets, then I might want to exclude swing from auto-import) HTH Auto-importing has to solve the problem of reasonably inferring the intentions of the programmer- do they want to import a class or create a class or create an inner class? It's impossible to know for sure, but something like the following would go a long way to enhancing auto-import. Netbeans should auto-import when a class unambiguously matches one in packages which are 1) very common (java.* javax.* etc.). For example, I am guessing that most people use the libs in the JDK, even though there classes with the same names in say, trove. People using trove often times want it for ONE package or even a specific class. So an option would be to always auto-import from the JDK even if matching trove classes were found. satisfactory tweaking of this default behaviour might be achievable using 3 below . 2) OR listed explicitly by the developer on a configuration screen. 3) AND not on a developer-specified excludes list (say if I were creating my own swing widgets with the same names as the original swing widgets, then I might want to exclude swing from auto-import) HTH If this is implemented, then there should be a way to disable it. IMHO, I would not like IDE making decisions for me: would lead to bugs of difficult identification. Perhaps, when I work with GWT, lots of classes has similar names as the ones found in Swing and other packages, and sometimes I have to correctly choose from one or other. |