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

[Andrew Clement <CLEMAS@xxxxxxxxxx>]

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