Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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





Back to the top