Re: [jdt-core-dev] Sort members of a compilation unit

[Jim_des_Rivieres@xxxxxxxxxx]

I take Martin's suggestion to be simply to follow Olivier's basic plan (1) 
except use the existing ASTNode API rather than define a brand new API 
class SortJavaElement. Where Olivier's proptotype implementation now 
creates an instance of SortJavaElement, it would instead create an 
instance of an appropriate ASTNode subclass. These ASTNodes get passed to 
the client's Comparator. This is no requirement to use 
AST.parseCompilationUnit to create these nodes, and no suggestion that 
these nodes could be used for any other purpose.

Source range info also needs to be passed to the Comparator. As Philippe 
points out, there are differences between the source ranges for 
IJavaElements and those for ASTNodes. To be useful in this setting, the 
ASTNodes would need to carry accurate IJavaElements source ranges. The 
choice is to either spec that these ASTNodes will carry additional 
properties (ASTNode.getProperty("JavaElementOffset"), 
getProperty("JavaElementLength")), or to bend the rules to suite. Either 
would work fine.

This approach has the merits of not requiring new API, and provides a 
solution that is richer and more typesafe that a union type like 
SortJavaElement.

---jeem





"Philippe P Mulet" <MULETPP@xxxxxxxxxx>
Sent by: jdt-core-dev-admin@xxxxxxxxxxx
01/17/2003 09:47 AM
Please respond to jdt-core-dev

 
        To:     jdt-core-dev@xxxxxxxxxxx
        cc: 
        Subject:        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





_______________________________________________
jdt-core-dev mailing list
jdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-core-dev