Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Patch to create ICoreModel interface 

On Mar 28, 2005, at 3:17 PM, Alain Magloire wrote:
I have submitted a bugzilla enhancement request to create an ICoreModel 
interface that org.eclipse.cdt.core.model/CoreModel.java implements.
If I can figure out how to submit a patch to bugzilla, I will submit a
patch for the org.eclipse.cdt.core plugin.

Two major problems with using the CDT to create Fortran Development
Tools (without copying the entire CDT) is that the CCorePlugin and
CoreModel objects cannot be replaced by other language versions.
Creating an ICoreModel interface is a simple first step toward allowing 
a Fortran version.

.................
But lets make sure we are on the same length about the ICElement hierarchy. 
It was created for a few reasons:


...................

Now, the questions:

- Is the current ICElement hierarchy correct for you ?
  - if not ... how do you see the hierachy.
Very instructive. I have been mainly looking at working with (and around) 
CCorePlugin and have ignored CoreModel/ICElement.  After looking
carefully at ICElement.java I believe that all of it safely maps to Fortran, except for the constants representing a C/C++ children of a Translation Unit.
In fact, I would suggest changing the names of some interfaces to represent this. 
For example (CL stands for Common/Compiled Language):

ICModel -> ICLModel
ICProject -> ICLProject
ICContainer -> ICLContainer

and getCProject -> getCLProject
It seems to me that the ITranslationUnit interface even works as is for Fortran. 

I see an advantage to having language independent projects (CL_PROJECT),
in that, one could mix C/C++ and Fortran within one project.


- there is a method ICElement.getElementType(), looking at this
  not sure it will scale well, do you see this as a problem ?


I'm not sure what you mean by scaling (too many types for multiple
languages?) but I don't see a problem with defining Fortran types, such
as F_DERIVEDTYPE (equivalent of C_STRUCT).
If the proliferation of languages becomes excessive, perhaps the types could 
be broken into language dependent files.


- The IPathEntry hierarchy(include files, macros etc ..) any of this
  map to Fortran ?


I believe so.  Fortran doesn't have an equivalent for CDT_MACRO but
I don't see this as a problem.

Cheers,
Craig

Back to the top