RE: [ajdt-dev] one structure model to rule them all

["Mik Kersten" <beatmik@xxxxxxx>]

This all sounds good to me Matt.  Let's discuss further during this week's
call.

Mik

> -----Original Message-----
> From: ajdt-dev-admin@xxxxxxxxxxx [mailto:ajdt-dev-admin@xxxxxxxxxxx] On
> Behalf Of Matt Chapman
> Sent: Saturday, December 18, 2004 12:52 PM
> To: ajdt-dev@xxxxxxxxxxx
> Subject: Re: [ajdt-dev] one structure model to rule them all
> 
> In order to get the cross references / relationships view and the advice
> image decorator working properly, I ended up prototyping what the AJDT
> side of this might look like. There is now a layer on top of the ajde
> structure model which converts that IProgramElement based model into an
> IJavaElement based one, and so then the above functionality uses only this
> new model. I've refactored a bit post-M2, so the code is now mainly in the
> ajdt.core plugin, in the org.eclipse.ajdt.core.model package. After a
> build AJModel.createMap() is called do the conversion. The AJProjectModel
> class constructs a per-project
> relationship map for those IJavaElements which are involved in a
> relationship.
> 
> I think the next step is to try to use this new model elsewhere in AJDT,
> such as for creating the markers, and in the visualiser. I think we still
> need the line number information for these features, so we might actually
> end up with our own nodes with contain the IJavaElement, plus the
> additional information we need. For example the cross references view
> actually shows AJNodes (package org.eclipse.ajdt.internal.builder) which
> consist of IJavaElements with a label, as we want to use a longer name to
> indicate where it comes from, rather than just the name of the element.
> 
> The issue with the code elements beneath the level of normal IJavaElements
> is indeed a tricky one. I created an
> org.eclipse.ajdt.core.javaelements.AJCodeElement class to represent these.
> These are created when we find an IProgramElement that doesn't directly
> correspond to an IJavaElement. There are not added to the JavaCore model,
> but added to our structure when needed, such as when the cross reference
> view is populated.
> 
> Once the new model is well-defined enough to be used right across AJDT,
> I'd like to consider the possibilty of getting this new model directly,
> not creating IProgramElements at all. We can then persist this new model
> in the .metadata directory instead of .ajsym files. Utimately all these
> changes should both increase performance, and reduce memory usage.
> 
> So please take a look at the mentioned classes and see what you think. As
> Andy says, I think a key point is whether we can get to a world without
> IProgramElements.
> 
> Regards,
> 
> Matt.
> 
> 
> 
> 
> Andrew Clement/UK/IBM@IBMGB
> Sent by: ajdt-dev-admin@xxxxxxxxxxx
> 18/12/2004 10:09
> Please respond to
> ajdt-dev@xxxxxxxxxxx
> 
> 
> To
> ajdt-dev@xxxxxxxxxxx
> cc
> 
> Subject
> Re: [ajdt-dev] one structure model to rule them all
> 
> 
> 
> 
> 
> 
> 
> Hi Mik,
> 
> Yes, I think that is a good idea.  Incidentally I've just added a bit
> extra
> to the handles so they now include offset through the file (Eclipse uses
> it rather than recalculating it from the line number info).
> 
> Can I check if you are proposing that in an AJDT world we lose the
> IProgramElement
> model of each project - and just have the relationships? Eclipse will talk
> in
> terms of IJavaElements using eager parsing to get the structure it needs
> for the outline view/package explorer?
> 
> cheers,
> Andy.
> 
> 
> 
> "Mik Kersten" <beatmik@xxxxxxx>
> Sent by: ajdt-dev-admin@xxxxxxxxxxx
> 17/12/2004 21:19
> 
> Please respond to
> ajdt-dev@xxxxxxxxxxx
> 
> 
> To
> <ajdt-dev@xxxxxxxxxxx>
> cc
> 
> Subject
> [ajdt-dev] one structure model to rule them all
> 
> 
> 
> 
> 
> 
> 
> 
> 
> We finally seem to be both have more support for working directly with the
> Java Model, and more need to do so.  Here's an idea for a light-weight
> update to our architecture that will give us transparent access for
> working
> with the relationship map using either the IJavaElements or
> IProgramElements.
> 
> The idea is that we change the handle identifiers, used for storing
> entries
> in the map, to be the same those used by the JavaModel, i.e.
> IJavaElement.getHandleIdentifier().  That will allow us to ask for
> relationships for IJavaElements, and get back a list of handles that an
> adapter can turn into IJavaElements.
> 
> Currently our identifiers are a source location including path, line, and
> column number.  The Java model uses the handles that look like the
> following, "=Project-l/src<pkg1{Foo.java[Foo~m1", which uniquely identify
> members, are stable across builds and Eclipse invocations, but don't go
> below the member signature.  So our adapter will have to extend these by
> appending either line/column or offset information to reach at "code"
> elements (e.g. calls, handlers).  That's doable, and these handles should
> just get ignored by JavaCore as desired.  But I'm wondering what they
> should
> correspond to in our extended Java Model, perhaps a subtype of
> SourceRefElement called ICodeElement?  We should get JDT Core to add
> something like that anyway, but they'll probably want to call it
> IUnknownElement or IGenericRefElement to provide other projects with the
> same sort of extensibility.  Another challenge will be generating the
> project part of the handle because our compiler doesn't know about
> workspaces.  I hope that info can be extracted from the full path and
> source
> path information.  Then for other IDEs we can simply use the same relative
> path convention.
> 
> Let me know what you think and I'll consider raising an enhancement report
> and implementing the AspectJ side of this.
> 
> Mik
> 
> --
> http://kerstens.org/mik
> 
> 
> 
> _______________________________________________
> ajdt-dev mailing list
> ajdt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/ajdt-dev
> 
> 
> _______________________________________________
> ajdt-dev mailing list
> ajdt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/ajdt-dev