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

["Alain Magloire" <alain@xxxxxxx>]

> > 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
> 

I would go the opposite not renaming but extending.

interface ICProject extends ICLProject {
	// contains specific methods for C/C++
} 

See more below at the (***)

> 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.
> 

Yes.

> > - 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.
> 

Lets tackle this one in a different email.  Basically the IPathEntry hierarchy
was a way to isolate the core model from the builders.  The information;
include paths, libraries, macro definitions etc ... was provided to the
core model via this interface.

(***)
Allright, this will be painfull but bear with me.

Maybe, it would be easier to start clean in defining the common language interface,
we can worry how to bring the pieces together later.
We need to understand, what the different players(C and Fortran) need from this interface.

So I'll explain a little about the ICElement and what we get
out of it for C/C++.

The ICElement hierarchy can be separated in two:
(1) - how the Model views the world/resources (all classes above ITranslationUnit)
(2) - how the Model views the world/language (all classes below ITranslationUnit).

How we(C/C++) view the resources:
- ICModel  --> [root of the model]
	- ICProject --> [IProject with special attributes/natures]
		- ISourceRoot --> [Folder with a special attribute]
			- ITranslationUnit --> [IFile with special attributes, for example extensions *.c]
			- IBinary --> [IFile with special attributes, elf signature, coff etc...]
			- IArchive --> [IFile with special attributes, "<ar>" signature] 
			- ICContainer -> [folder]

There are also some special helper classes
	- ILibraryReference [external files use in linking ex:libsocket.so, libm.a, ...]
	- IIncludeReference [external paths use in preprocessing i.e. /usr/include, ...]
	- IBinaryContainer [virtual containers regrouping all the binaries find in the project]

This model of the resources gives advantages:
- navigation of the binaries, 
- navigation of the include files not part of the workspace (stdio.h, socket.h, etc ...)
- adding breakpoints
- search
- contribution on the objects
etc.....

Question:
- how do fortran see the resources(folder, files, binaries ...) ?
- Any special use of the resources ?
   For example in Java, folders are special, i.e  java.lan.InputStream
   must be in folders java/lang/InputStream.{java,class} so the the folders
   map to the packagenames.
- Any other (external)files should be visible from the model ? libraries(*.so, *.a), jar(*.jar) ?


For example the Fortran factory(ICoreModel) could create an hierachy, 
 - ICLModel
   - ICLProject  --> [IProject with Fortran nature]
   - ICLTranslationUnit -> IFile with *.f extensions
   ....

The C Model Factory(ICoreModel)
  - ICLModel
     ICLProject --> ICProject [IProject with with C/C++ nature]


So if we could agree on the model resources, that's a good start.
Refactoring the ICProject, ICContainer,... to be on top on the new hierarchy
should not be a big deal or not even necessary in some cases.
 
(2) How we view the language.

Lets be clear this is only a simple/partial/incomplete view of the language.
For example, we do not drill down in blocks, there are no statements(if/else conditions) etc ....
For a complete interface/view of the language, clients should use the __AST__ interface.
We could things easier for the clients:

	IASTTranslationUnit ICLTranslationUnit.getAST();

... but this email is already too long ...  8-)