Re: [cdt-dev] Patch to create ICoreModel interface

["Alain Magloire" <alain@xxxxxxx>]

> 
> 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.
> 
> Additional steps that will be needed are to move static methods (ones 
> that are language neutral) in CoreModel and CCorePlugin to other 
> classes (for example, CLCoreModel; CL for common language or compiled 
> language).  Static methods that are language dependent should be made 
> normal, non-static methods to allow for polymorphism.
> 
> The patch also modifies CCorePlugin.getCoreModel() to return the 
> ICoreModel interface, rather than the CoreModel singleton.
> 
> There still needs to be a mechanism to get at the correct Core Model 
> for a given language.  One way to do this would be to provide methods 
> in a new class, say CLCoreManager, to return the correct 
> language-specific class implementing ICoreModel, based on context.  For 
> example, CLCoreManager,getCoreModel(IProject project) could return the 
> C CoreModel if the project had a C or C++ nature.
> 
> I'm still experimenting with the implication of this and various ways 
> to implement it.  When I learn more, I'll come back with a more 
> concrete proposal for comment.  In the meantime, I think getting the 
> ICoreModel interface into the main branch should be a non-controversial 
> first step.
> 

IMHO, I think this approach is better then to overload Plugin.getDefault().

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

- To provide a simpler layer to the AST.  The AST interface is too complex
  to handle in most UI tasks.
- To provide objects for UI contributions/actions.
- The glue for the Working copies in the Editor(CEditor), IWorkingCopy class
- The interface for changed events.
- ...

Basically it was created for the UI needs: Outliner, Object action contributions,
C/C++ Project view and more.

The CoreModel uses information taken from:
- the Binary Parser(Elf, Coff, ..)
- the source Parser(AST parser)
- the IPathEntry classes
- the workspace resource tree
- The ResolverModel (*.c, *.cc extensions), ...

to build the hierarchy.

Now, the questions:

- Is the current ICElement hierarchy correct for you ?
  - if not ... how do you see the hierachy.
- there is a method ICElement.getElementType(), looking at this
  not sure it will scale well, do you see this as a problem ?
- The IPathEntry hierarchy(include files, macros etc ..) any of this
  map to Fortran ?


Thanks.