| [cdt-dev] RE: [photran] ITranslationUnit and Language Independence |
|
Cool, thanks. I was envisioning a parallel ILanguageUI
that was one-to-one with an ILanguage to handle UI extensions such as label
providers for the outline view. My vision is that these interfaces will handle
everything necessary to adapt the cdt.core and cdt.ui to a new language. I
guess I should take some time and write down what I’m trying to do and
share it with you all J. Cheers, Doug From:
photran-bounces@xxxxxxxxxxx [mailto:photran-bounces@xxxxxxxxxxx] On Behalf Of Treggiari, Leo 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. |