Community
Participate
Working Groups
When the workbench preference Java>Work in Progress>Fill Arguments on method completion is set then code assist on method declaration doesn't work. Suspect that the template code doesn't distinguish between method completion and method declaration completion. (Dirk this explains why it didn't work for us) Also we need to decide whether we promote this feature from experimental to real. I vote for yes it is useful (if this bug is fixed)
How many votes do we need?
+1 My two cents
actually, the feature would be even more useful if it did some argument guessing as is done in template completions.
the original bug is fixed >= 20020311. degrading priority for the other requests.
*** Bug 10477 has been marked as a duplicate of this bug. ***
Created attachment 754 [details] JAR containing 4 modified files from the 05022002 build.
Please see attachment. I have been playing around with this problem.. and I would like to submit some code that does parameter guessing on method completion, using the current ExperimentalResultCollector and ExperimentalProposal classes. The code is written and tested against the latest integration build (05022002). The patch will only significantly affect ExperimentalResultCollector, minor modifications are made to the Preference page classes and the messages properties file to promote this behavior as a preference -- those three changes are one-liners. Total changes involve 4 files, 3 java and one .properties. The code registers a second ICompletionRequester to track local and member variables, and store their types and names. When a method completion is triggered, for each parameter in the completing method, it searches the stored variables for the closest variable that matches the type of the parameter in the method being completed. "Closest" means it will take a local variable before a member variable, and it searches the list in the reverse order they are reported to the ICompletionRequester, which works out to be "closest" (in terms of character position of declaration) to the point of the method completion. Current limitations: Packages of types are not reported by the CompletionEngine for local variables, so type matching is limited to the typeName for local variables. In addition, package names are not currently tracked in the protected API of ResultCollector, so effectively, packages are always ignored (even for non- local variables, where it is theoretically possible). This second issue can be fixed by slightly modifiying ResultCollector, but I wanted to limit the "patch" the minimum number of classes. If the ResultCollector protected API is modified to accept package names AND the CompletionEngine/local variable type binding report packages of local variables, packages can be included in computing a match. It will not recognize variables that match the type because of inheritance or interface implementations unless the variable is declared to be of the exact type the method parameter expects. This cannot be fixed until the packages are always available, and would require loading Class objects for the variable type and the parameter type, and using isAssignableFrom(). This might be a performance problem (Class.forName() calls, etc). It does not concern itself with variable naming. In theory, if there are multiple type-based matches, a "best match" might be determined by comparing the variable name to the parameter name and choosing the "closest". However, it is unclear what the algorithm would be, and it also might represent a performance issue. Preference: The preference for "guess parameter name" is dependent on the "Fill in method argument names" preference, but I do not know how to enforce that relationship in the preferences UI. Performance: This approach will have an impact on performance equal to the time necessary to trigger a second code completion for the purpose of tracking local and member variables. That is, each code completion will actually involve two invokations of the CompletionEngine, with the second invocation having no UI effect, and limiting it's concern to local and member variables. I would appreciate any feedback you have, and of course I hope you can/will use the code :) Thanks, Andrew - a huge eclipse fan trying to put my-money-where-my-mouth-is mccull1@us.ibm.com
Created attachment 755 [details] This is a diff on HEAD for JDT-UI as of 05/04/2002 - i realized this may be more useful
Thanks Andrew, I'll have a look.
Created attachment 1335 [details] New Version of same thing, uncludes inherited/interface type matching
The previous attatchment contains the latest version of the parameter guessing code. Major changes include using basic substring matching for smarter guessing, and using the SuperTypeHierarchy from JDT to match types other than the declared type (implemented interfaces, subclasses, etc). I am also posting this to the newgroup figuring the odds of getting this in for 2.0 are slim to none :) I also removed the preference page as I am trying to treat this as a patch to JDT-UI, and have no way of contributing to the Code Assist preference page.
check it in the base!
I have created a SourceForge project for this little patch. FYI, there was a bit of a bug that is now fixed that caused a problem when completing with no prefix (e.g. varName.<complete>). Sourceforge will be the place to find the code in the event that someone wants to use it. I will stop attaching to this bug report. http://sourceforge.net/projects/completeclipse -Andrew
Created attachment 1755 [details] Latest completion-guess code.
Patch to HEAD (2.1 stream) for JDT-UI. I Suggest that a preference be added, but otherwise functional when "Fill in.. " is selected. By making some of the private methods and variables in ResultCollector protected, some code can be removed/refactored, but I have tried to keep changes to JDT-UI code to a minimum for my own maintenence sanity. -Andrew
*** Bug 14497 has been marked as a duplicate of this bug. ***
fixed >= 20020812 released modified patch from 20020728 attached by Andrew. Thanks a lot for the contribution!
