Bugzilla – Full Text Bug Listing
| Summary: | Duplicate code in AbstractTemplateCompletionProposalComputer implementations | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Simon Scholz <simon.scholz> |
| Component: | Text | Assignee: | JDT-Text-Inbox <jdt-text-inbox> |
| Status: | ASSIGNED --- | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | daniel_megert, Lars.Vogel |
| Version: | 4.5 | Keywords: | api, investigate |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: | https://git.eclipse.org/r/39338 | ||
| Whiteboard: | |||
Here is my proposed improvement: https://git.eclipse.org/r/#/c/39338/ (In reply to Simon Scholz from comment #0) > Besides the (default) TemplateCompletionProposalComputer implementation a > SWTTemplateCompletionProposalComputer and an > E4TemplateCompletionProposalComputer has been created. In which project? Does that depend on JDT? The E4TemplateCompletionProposalComputer(In reply to Dani Megert from comment #2) > (In reply to Simon Scholz from comment #0) > > Besides the (default) TemplateCompletionProposalComputer implementation a > > SWTTemplateCompletionProposalComputer and an > > E4TemplateCompletionProposalComputer has been created. > > In which project? Does that depend on JDT? The E4TemplateCompletionProposalComputer is part of the org.eclipse.e4.tools.core project and shares common code, which would be reduced by using the AbstractClasspathDependendTemplateCompletionProposalComputer class. And I think it is a great feature to only show template proposals in case certain artifacts are in the classpath, like SWT, E4, JFace and more. Can this be reviewed for 4.6 M2? (In reply to Lars Vogel from comment #4) > Can this be reviewed for 4.6 M2? There is no new change after my review from April. |
Besides the (default) TemplateCompletionProposalComputer implementation a SWTTemplateCompletionProposalComputer and an E4TemplateCompletionProposalComputer has been created. Those implementations are nearly the same, so that we have redundant code here. And the AbstractTemplateCompletionProposalComputer is internal so that the E4TemplateCompletionProposalComputer also uses the @SuppressWarnings("restriction") annotation. In a customer project we also have another implementation of the AbstractTemplateCompletionProposalComputer, and therefore even more redundant code. I like to implement another abstract class in between with default behaviour for those at least 3 pretty similar implementations in order to avoid this redundant code. Another issue is that I like to make this class API so that we do not need the @SuppressWarnings("restriction") annotation in other project, but this would be a different bug. What do you think about my plans?