Hi Andy,
Yes, what I’m proposing is that we
take this step so that in order to make the eventual move away from the
org.aspectj.asm.IProgramElement API easier for AJDT. How quickly that move
happens can be determined by AJDT’s needs, and it looks like Matt is already heading in this direction.
So this means that we would have a
special build option that would suppress the creation of the IProgramElement hierarchy,
but still build the relationship map as before (using the new handles).
Then, as you indicate, when AJDT asks for a related element JavaCore can create
it from the handle if it is not available.
We will still need to keep the
IProgramElement generation around for ajdoc, jdeveloper, and jbuilder/netbeans should
those get resuscitated. The tradeoff that we’re making is to rely
on the Java Model as the canonical model for the containment hierarchy, and to separately
continue maintaining the IProgramElement hierarchy. So it’ll
probably be a long time before we extend it to handle enums and annotations,
where the Java Model already has them. We can’t translate from the
Java Model to the IProgramElement model because the former is coupled to the
Workbench, which cannot be embedded within other IDEs. But this should be
a significant benefit to AJDT, and we can support the IProgramElement hierarchy
on a demand-driven basis.
I’ve created the following bug
report for discussing any implementation issues:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=82171
Mik
From:
ajdt-dev-admin@xxxxxxxxxxx [mailto:ajdt-dev-admin@xxxxxxxxxxx] On Behalf Of Andrew Clement
Sent: Saturday, December 18, 2004
2:10 AM
To: ajdt-dev@xxxxxxxxxxx
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
