RE: [cdt-dev] Core Model (was: Binary parser proposal)

["Amer, Hoda" <hamer@xxxxxxxxxxxx>]

Hi Alain,
I am currently working on the items you have listed below. I already have
the LRU cache in place. I am currently working on the Working Copies. My
next working item would be the deltas for translation units. 

For the IStructure, I've found out that a class, a struct, and a union are
all grouped together in the C++ standards. It would be helpful if you point
out the changes required to make it less confusing for the C Projects.

The one thing I did not investigate and did not plan to work on is the
ICResource changes for copying, moving, etc... 

So how do you propose we continue from here?
Thanks
Hoda

-----Original Message-----
From: Alain Magloire [mailto:alain@xxxxxxx] 
Sent: Thursday, February 20, 2003 5:52 PM
To: cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] Core Model (was: Binary parser proposal)

> 
> Hi Alain,
> 
> I'm not sure what you mean by "work on".  Hoda has already started much of
> the work she had proposed and is currently focused on to getting the
Working
> Copy running.  Please co-ordinate with her any work activities so that we
> don't have any duplication.

Yes,
It was the intent of this email; tell the rest of the folks the area I was 
planning to change and why.  Assuming, Hoda was monitoring this list.
Thanks for the note, I will forward the email to her.

> 
> Cheers,
> Doug Schaefer
> Senior Staff Software Engineer
> Rational - the software development company
> Ottawa (Kanata), Ontario, Canada
>  
> 
> -----Original Message-----
> From: Alain Magloire [mailto:alain@xxxxxxx] 
> Sent: Thursday, February 20, 2003 12:31 PM
> To: cdt-dev@xxxxxxxxxxx
> Subject: Re: [cdt-dev] Core Model (was: Binary parser proposal)
> 
> > 
> > This is cool stuff, Alain.  I like where you guys are going with this.
> > 
> > Given that the functionality you describe is going to be accessible from
> the
> > C/C++ Project View, is it really necessary to implement the IResource
(and
> > friends) interface in the core model (class Resource and subclasses)?
> This
> > doesn't seem necessary for other elements that represent Eclipse
resources
> > (e.g. CFile).
> 
> Yes to all the above.
> 
> I probably did not make this clear, the way it was implemented was
> incorrect.
> At the time, it was the easiest route; the Core Model API was incomplete.
> We should have methods in the Core Model to manipulate ICElement that
> includes
> copy/move/etc ... actions, see (1) proposition below.
> 
> Now going back to the Core Model Proposal(Hoda's paper in cdt-core-home),
> few things are missing and some are incomplete/confusing, below are some
> obvious problem.
> 
> I will start to work on, in that order:
> (2),
> (1),
> (3),
> (4),
> (5),
> (6)...
> 
> If no objections.
> 
> (3) is the hardest, putting the working copy, because it touches other
> plugin.
> 
> ======
> 
> (1)  Work on the ICResource --> ICRoot, ICProject, ICFolder, ICFile
> 
>   We need the same to work on the C Resources(ICRoot, ICProject, ICFolder,
> ICFile).
>   I would propose something similar:
> 
>   public interface ICResourceManipulation {
>     void copy(ICResource src, ICFolder folder);
>     void move(...);
>     void rename(...);
>   }
> 
>   This would allow to copy/delete objects from an IArchive
> (libfoo.a(foo.o)).
>   or anything that the BinaryParser recognise as an Archive.
> 
> (2) LRU Caching 
> 
>   Simple caching is done but there is no bound on the map, this is
> incorrect.
>   The same way for IResource, ICElements are handles/proxies,
>   the real implementation is in CElementInfo.  The CElementInfos should be
>   cache in LRU.
> 
> **(3) Working Copy
>     A big piece
> 
> (4) Confusion in the model when C vs C++
>    C is not C++ 8-) and there is many example where things does not make
> much
>    sense.  For example the IStructure can be confusing in C.
> 
> (5) Deltas for translation Unit nodes.
> 
> (6) Implementation and iteration and iteration and ...
> 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-dev
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-dev
>