Bugzilla – Full Text Bug Listing
| Summary: | CDT DOM parser are x-friendly with CDT UI | ||
|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Alex Blewitt <alex.blewitt> |
| Component: | cdt-core | Assignee: | Project Inbox <cdt-core-inbox> |
| Status: | NEW --- | QA Contact: | Jonah Graham <jonah> |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | yevshif |
| Version: | 6.0 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 315539 | ||
|
Description
Alex Blewitt
The coupling between the UI plugin and the core plugin is not as tight as your comment suggests. It is mostly because of reusing some utilities from internal core packages. Some of these could certainly be made API. You can always ask for that. Because we did not have a public way of creating AST nodes before CDT 7.0, the refactoring creates internal AST nodes. All of that could be changed now. However, there is a different reason why the implementation for the AST interfaces need to be part of CDT: Any implementation outside of CDT will stop us from making necessary changes (e.g.: evolving the AST to handle c++0x). Therefore the interfaces are marked as @noimplement. A support for another language can only be successful if the AST for that language is an integral part of CDT. (It does not really matter where the parser is implemented). After all you do want to have tooling on top of the AST and you want to reuse existing tooling. Therefore the tools need to able to use the AST of the language added. If you write your own tools, then you can do your own AST. (In reply to comment #1) > However, there is a different reason why the implementation for the AST > interfaces need to be part of CDT: Any implementation outside of CDT will stop > us from making necessary changes (e.g.: evolving the AST to handle c++0x). > Therefore the interfaces are marked as @noimplement. Right, I understand that concern. But then you end up writing your own AST by copying and pasting code (as the Objective C project did) which then falls over in the face of evolving CDT versions. > A support for another language can only be successful if the AST for that > language is an integral part of CDT. (It does not really matter where the > parser is implemented). After all you do want to have tooling on top of the AST > and you want to reuse existing tooling. Therefore the tools need to able to use > the AST of the language added. If you write your own tools, then you can do > your own AST. If that is the ultimate position of CDT - that it's either languages that are in the CDT or you do everything yourself, then there is very little point in writing an external language that uses any of the CDT tools - you might as well re-write those yourself, too. If CDT is about being closed, then please close my suggestions on how to make CDT more extensible as WONTFIX. |