[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-core-dev] Sort members of a compilation unit
|
One thing to keep in mind is that operation isn't meant to be a helper
method for AST operations.
If you believe you could implement it using the AST tree, then just go
ahead, you don't need an API to do so.
So far we are aware of issues around comments on AST, and such a sorting
algorithm would almost guarantee
tp hit these issues, and require the AST to be upgraded though we haven't
come up yet with a strategy for
associating comments with ASTs.
The approach of the ICompilationUnit sort API is strictly sticking to
IJavaElement definitions. The source range of
an element is the one considered here, and corresponds to what users see in
the outliner.
Given there is no element available for local types/members, we cannot
unfortunately let users implement it based on
our existing APIs, nor can we pass handle to the member elements to a
Comparator API (since no handles in local type).
We have 3 solutions:
- go ahead and follow OIivier's idea
- let clients implement it on IJavaElement API - no sorting for local
members
- let clients implement it on AST API - issues with comment
"Martin Aeschlimann" <Martin_Aeschlimann@xxxxxxx>@eclipse.org on 01/17/2003
12:47:46 PM
Please respond to jdt-core-dev@xxxxxxxxxxx
Sent by: jdt-core-dev-admin@xxxxxxxxxxx
To: <jdt-core-dev@xxxxxxxxxxx>
cc:
Subject: Re: [jdt-core-dev] Sort members of a compilation unit
Instead of using a new type SortJavaElement, could't we use the ASTNodes of
type BodyDeclaration?
You could create them using AST.newXX... and use the setters on the ASTNode
to set the properties (including updated positions). You could specify that
the passed nodes contain no bodies, no initializers and are not resolvable.
Martin
_______________________________________________
jdt-core-dev mailing list
jdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-core-dev
