Closed reprogrammer closed 13 years ago
@vazexqi: So far, Eclipse has recorded about 20 invocations of this refactoring (org.eclipse.jdt.ui.infer.typearguments
) from our participants. So, I suggest to capture this refactoring next.
@vazexqi: f00c8225f6ec56791125921e640b0bf6dfa32c9a .. 6a931c8d5d7cb736045c03c4d71c12d784dde981 capture invocations of infer type arguments. I manually invoked the refactoring using quick assist. But, CodingSpectator didn't recognize that the refactoring was invoked via quick assist. Besides, I didn't find a case where the refactoring is not available. But, just from reading the code, I guess the refactoring is unavailable when JRE 1.5 is not available.
@vazexqi: CodingSpectator doesn't record the invocation of the refactoring as a use of quick assist because it's a quick fix and not a quick assist. The quick fix proposal for infer type arguments is implemented at LocalCorrectionsSubProcessor#addTypePrametersToRawTypeReference
. Also, infer type arguments is not list at org.eclipse.jdt.internal.ui.text.correction.QuickAssistProcessor
, which is another evidence that there is no quick assist for infer type arguments. Note that CodingSpectator marks such an invocation of the refactoring as one invoked via a structured selection because the quick fix proposal invokes org.eclipse.jdt.ui.actions.InferTypeArgumentsAction.run(IStructuredSelection)
.
In summary, this issue is not due to a bug in CodingSpectator but it questions our assumption that quick fixes do not invoke refactorings. If we'd like to study the impact of Eclipse suggestions on the invocations of refactorings, we have to consider some of the quick fixes.
I created issue #323 to capture invocations of this refactoring via Quick Fix.
This refactoring accounts for about 0.3% of the invocations of refactorings in the UDC data.