[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-core-dev] No java model representation for anonymous classes and named local classes
|
The problem, as you say, it coming up with a way to assign such objects a
global identity that would persist across parses of the compilation unit.
The property that is needed is that they are reasonably stable. Clients can
hold on to a handle object (IJavaElement) that records little more of the
id. Every time they access the handle, the id is used internally to find
the appropriate object of the Java model. To the extent that the ids are
stable, the handles will continue to be useful to the client as the Java
model changes. Stable ids also underwrite the whole notion of Java element
deltas which are framed in terms of Java element handles.
The idea of having Java element with no stable id would not work well. It
would mean that every time you reparsed a compilation unit, these elements
would be given a brand new id. When new elements are created, or old
elements go away, we issue a Java element delta describing what has
happened. We do this so that clients hanging on to these handle can react
to those changes. In the worst case scenario, closing and reopening a
compilation unit element would result in a delta that shows a set of
elements with unstable ids being deleted and another set of elements being
created. So you would get lots of swirlt and apparent change even though
absolutely nothing about the compilation unit had changed. That would be
bad.
re: initializers not having stable ids - If you look into it, you'll see
that IInitializers are given relatively stable ids, albeit ones based on
their relative position in the compilation unit. The ids have the flavour
"the first initializer in (handle for compilation unit Foo)", "the second
initializer in (handle for compilation unit Foo)", and so on.
Position-based ids are stable over most changes except adding or deleting
an initializer at the same or earlier position.
So why don't we use a similar approach to give ids to local and anonymous
classes? Something like "the first anonymous class in (handle for method
Foo.bar())", etc. The only answer I can give is "history". First there was
JDOM (which has no handles or stable ids). JDOM elements are no finer than
entire methods, which was sufficient at the time for the intended purpose
of allowing parties to browse compilation units and add, remove, or replace
methods. The Java model came next (which does have handles and stable ids),
and was built on atop JDOM. Again, it was sufficient at the time to go no
finer than entire methods. This is all pre-Eclipse 1.0. In 2.0, we added
the new find-grained AST API and moved refactoring over to it (it had been
using the compiler's internal ASTs, JDOM not being fine-grained enough to
be an option).
So if we were to take the next logical step, we would rehost the Java model
on the AST API and be in a perfect position to extend the Java model with
finer-grained elements such as local and anonymous classes.
---jim
"Rory
Lucyshyn-Wright" To: jdt-core-dev@xxxxxxxxxxx
<Rory_Lucyshyn-Wrig cc:
ht@xxxxxxx> Subject: [jdt-core-dev] No java model representation for anonymous classes and named
Sent by: local classes
jdt-core-dev-admin@
eclipse.org
11/20/2002 09:51 AM
Please respond to
jdt-core-dev
It was suggested to me that the reason why there is no java model
representation for anonymous classes and named local classes is that there
is no obvious or reasonable way to assign such a class a global identity
that would persist across parses of different editions of the class'
containing compilation unit. By this I mean that there is no obvious and
reasonable way to determine whether such a class is "the same class as" a
class found in a subsequent parse of a different edition of the same
compilation unit.
This suggestion led me come upon the idea that, in the design of a Java
Model like that of JDT, it could be possible to have Java elements which do
not have a global identity that persists across parses of the compilation
unit in which they occur, and that this could likely be a reasonable way to
treat anonymous and named local classes. An IJavaElement representing such
a class could cease to "exist" (i.e. !element.exists()) after a parse of a
differing edition of the same compilation unit and a new element could come
into existence as a child of the same parent.
In fact, it appears that there may already be elements with some of these
properties. IInitializer elements represent stand-alone instance or class
(static) initializers in a type. As in the case of anonymous and local
classes, there does not appear to be any obvious or reasonable way to
assign an initializer a global identity that would persist across parses of
differing editions of the compilation unit.
So, with awareness of what is written above, what is the reason why there
is no java model representation for such classes?
_______________________________________________
jdt-core-dev mailing list
jdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-core-dev
