[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
>
