[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-core-dev] start position in DOM
|
Ok, I checked the Type/MethodDeclaration nodes, and their source range
actually includes the leading javadoc (exactly one if any), as I had
guessed from looking at the implementation.
Since it is spec'ed as such, I will leave it as it is. We may want to
provide an extendedStartPosition() which would allow some degree of
consistency with other source ranges in our other APIs.
|---------+------------------------------>
| | Jim des |
| | Rivieres/Ottawa/IBM|
| | @IBMCA |
| | Sent by: |
| | jdt-core-dev-admin@|
| | eclipse.org |
| | |
| | |
| | 07/02/2003 06:53 PM|
| | Please respond to |
| | jdt-core-dev |
| | |
|---------+------------------------------>
>------------------------------------------------------------------------------------------------------------------------|
| |
| To: jdt-core-dev@xxxxxxxxxxx |
| cc: |
| Subject: Re: [jdt-core-dev] start position in DOM |
| |
>------------------------------------------------------------------------------------------------------------------------|
> Is there anything better than this ? BTW, I understand the DOM clients,
and
> will not change their assumption.
DOM AST source ranges are spelled out in AST.parseCompilationUnit
(responsible for setting source ranges):
The returned compilation unit node is the root node of a new AST. Each
node in the subtree carries source range(s) information relating back to
positions in the given source string (the given source string itself is
not remembered with the AST). The source range usually begins at the first
character of the first token corresponding to the node; leading whitespace
and comments are not included. The source range usually extends through the
last character of
the last token corresponding to the node; trailing whitespace and comments
are not included. There are a handful of exceptions (including compilation
units
and the various body declarations); the specification for these node type
spells out the details. Source ranges nest properly: the source range for
a child is always within the source range of its parent, and the source
ranges of sibling nodes never overlap.
Philippe P Mulet/France/IBM@IBMFR
Sent by: jdt-core-dev-admin@xxxxxxxxxxx
07/02/2003 12:30 PM
Please respond to jdt-core-dev
To: jdt-core-dev@xxxxxxxxxxx
cc:
Subject: Re: [jdt-core-dev] start position in DOM
Is there anything better than this ? BTW, I understand the DOM clients,
and
will not change their assumption.
/**
* Returns the character index into the original source file
indicating
* where the source fragment corresponding to this node begins.
*
* @return the 0-based character index, or <code>-1</code>
* if no source position information is recorded for this node
* @see #getLength
*/
public int getStartPosition()
|---------+------------------------------>
| | Jim des |
| | Rivieres/Ottawa/IBM|
| | @IBMCA |
| | Sent by: |
| | jdt-core-dev-admin@|
| | eclipse.org |
| | |
| | |
| | 07/02/2003 06:05 PM|
| | Please respond to |
| | jdt-core-dev |
| | |
|---------+------------------------------>
>
------------------------------------------------------------------------------------------------------------------------|
| |
| To: jdt-core-dev@xxxxxxxxxxx |
| cc: |
| Subject: Re: [jdt-core-dev] start position in DOM |
| |
>
------------------------------------------------------------------------------------------------------------------------|
> Any comments ? I checked the spec on the DOM AST, and it is only
loosely
> spec'ed, so it could be evolved.
Actually, the DOM AST specs source ranges quite tightly (refactoring needs
exact ranges to do source code rewriting).
Philippe P Mulet/France/IBM@IBMFR
Sent by: jdt-core-dev-admin@xxxxxxxxxxx
07/01/2003 11:11 AM
Please respond to jdt-core-dev
To: jdt-core-dev@xxxxxxxxxxx
cc:
Subject: [jdt-core-dev] start position in DOM
Something annoying me in our current parser implementations is that there
is no consistency in our starting positions amongst our different type of
nodes (compiler ast, dom ast, source elements, jdom).
This comes from the fact there are 2 implementations of
Parser#checkAnnotation which are subtily different. The JavaModel is
considering all comments behind previous element to be part of the next
element (taking into account trailing line comment). I would like to
generalize this behavior to others as well. The DOM only contains the
immediate leading javadoc comment, and we could enclose them all as we do
in the model.
Any comments ? I checked the spec on the DOM AST, and it is only loosely
spec'ed, so it could be evolved.
_______________________________________________
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
_______________________________________________
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
