| RE: [photran] ITranslationUnit and Language Independence |
|
Hi Doug,
This looks like the right direction to me. I have a few comments.
In general, I agree with having a *DT “language” extension point that: 1. Defines the information that can be defined statically for a language 2. Defines the class(es) that implement the interface(s) required to integrate a new language (e.g., ILanguage)
The ILanguage interface seems like it will serve a similar purpose to the IAdditionalLanguage interface proposed by the Photran team, but IAdditionalLanguage looks like it is also intended to allow the CDT Outline View implementation to support multiple languages. In addition to specifying language information for editor/code-assist functionality, we should also consider the information required for “common” views, like the Outline View. I suggest that the current C/C++ Projects View could be renamed to the “Project Explorer” and support all *DT languages. On the other hand, there are UI objects that I suggest remain language specific because of usability concerns – even if they share the majority of their implementation. This includes the New Project wizards and the language “perspective”.
Regards, Leo
From:
photran-bounces@xxxxxxxxxxx [mailto:photran-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
He gang,
I’m looking at the multi-language question from the CModel and DOM/Index perspective. As I mentioned in Leo’s Project Model proposal for *DT, my feeling is that the best point of entry into this world is through ITranslationUnit. I have created an interface ILanguage which serves a variety of purposes to allow language specialization of core functionality. I have a method on ITranslationUnit called getLanguage() which would figure out the language given the content type of the file that the TranslationUnit represents. I have an extension point that allows language developers to register an ILanguage implementation against a set of content types. The getLanguage method takes advantage of this extension point. This stuff is in HEAD right now, so you can check it out.
The problem I now have is that there is a lot of quasi-language dependant checking in ITranslationUnit, the main one being that ITranslationUnits are only valid for a hard-coded subset of content types. I’d like to get rid of this and add, where really necessary, the behaviour into ILanguage.
Any thoughts? Any counter suggestions on how to do this correctly? Doug. |