Having just read the blog post "The Road to Eclipse 4", I've remembered comments that I've made to an Eclipse bug report. I'm repeating them here, slightly edited, so that I don't lose them.
What's wrong with Eclipse today
It is still too hard to write programs for the RCP. These problems cannot be solved by only expanding Eclipse's functionality, there has to be consolidation, too. I'd like to see some of the impressive collective brain power behind Eclipse be used to come up with new ideas for handling large code bases (such as Eclipse itself).If Eclipse does not find a way of simplifying and innovating, I'm afraid it might be outmaneuvered by Netbeans in the long run. Netbeans has been quite courageous in refactoring its code base and version 6.0 has provided many new features, in a streamlined, highly integrated fashion.
Concrete suggestions for improving Eclipse
Below I've outlined how I think Eclipse can be improved.Improving the internals
- Better coding: Some of the coding patterns are ugly; Eclipse deserves better. Examples: Downcasts, factory not documented at product, constants hard to find (SWT is inconvenient and error-inviting, enums would be much better and not necessarily much more inefficient), long method invocation chains to get to a service provider (dependency injection might help here; if you want to see DI done well, look at Guice), too much nomenclature.
- Navigating plugins and the RCP framework: Eclipse does reasonably well when it comes to code, so dealing with the extension XML should be as easy as dealing with code and both should be even more integrated. Can we come up with new ways of making it easy to discover functionality and to find one's way around in the mix of artifacts that is currently supported by Eclipse? Better cross-artifact refactoring would not hurt either.
- Snippets: They are brilliant for looking up stuff, but shouldn't some of that code be encapsulated (e.g., turned into a method)?
- Netbeans has project "Schliemann". Does Eclipse have something similar?
New external features
- Finding code: Because one cannot extend classes a posteriori in Java, functionality is often put into separate classes, as static methods (e.g. Collections). How can one find this functionality if one does not know about it?
- Structuring code: One has to be able to mark up scattered concerns and to structure large classes. I've posted some ideas in response to an Eclipse bug report, that include making better use of the @category Javadoc tag.
- A simplified formal model for searching source code: One could store all source code associations as RDF and use SPARQL to query it or one could implement one's own Prolog-like query language, much like JQuery has done it.
- Multi-dimensional browsing: Currently displayed hierarchies such as the call hierarchy and the inheritance hierarchy cannot be mixed. Relo is an example of freely mixing these hierarchies. This feature is much easier to implement, if one has a formal model of the source code (see previous entry).
- Source code fragment editing: With polymorphism, one often needs to look at the declaration of a method together with all of its implementations. Eclipse should return search results as a sequence of source code fragements (I think member granularity is fine enough) and display all these fragments next to each other in a single editor.
Minor improvements
- Option: only refresh inheritance hierarchy on-demand, manually.
- F4 while on a method should immediately show members in the hierarchy.
ليست هناك تعليقات:
إرسال تعليق