Re: [jdt-core-dev] 1.5 source using a apilevel JLS2

[Martin Aeschlimann <martin_aeschlimann@xxxxxxxxxx>]

IMO 2.2 is not an option for the following
reasons:
- clients assume that the there are
node other node types that the ones available in the JLS2-AST. e.g. there's
code assuming that if a type is not PrimitiveType and not ArrayType it
is a SimpleType. Having a ParametrizedType there would lead to class cast
exceptions. 
- it is promised that all nodes in a
tree are visited by the visitor which wouldn't be possible with the new
nodes

I agree with Philippe that the problem
of 2.1 is to find good 'placeholder' nodes for malformed nodes. Besides
the ClassInstanceCreation case also the EnumDeclaration
and AnnotationTypeDeclaration
will be difficult. 
An additional problem with 2.1 is that
client code like might make assumptions from the node type on to what scanner
symbols to be found in the source. This code would definitely have to be
made 'malformed node aware'. 

For this reason I think 2.3 makes sense
as you would only find nodes in this tree that are really existing. As
said in the bug report, the idea of 2.3 would be to mark the parent as
malformed but have as many as possible children in it, if they can be correctly
parsed.
I should be said that in 2.3 a malformed
_expression_ can lead that its parent can not be formed, leading to a non
existing statement. So I also agree with Jerome and Philippe that the 2.3
strategy might result in quite a sparse resulting tree.

Maybe a solution would be a mix between
2.1 and 2.3 where we use placeholders when there is a good one (e.g. EmptyStatement
for ForEach) but also skip certain nodes if there's not (e.g. EnumDeclaration)

Martin

Philippe P Mulet/France/IBM@IBMFR
Sent by: jdt-core-dev-admin@xxxxxxxxxxx

2004-06-15 11:34

Please respond to
jdt-core-dev@xxxxxxxxxxx

To	jdt-core-dev@xxxxxxxxxxx
cc
Subject	Re: [jdt-core-dev] 1.5 source using a apilevel JLS2

I agree 2.3 is not useful. However, 2.1 is not much either. An empty
statement is a poor approximation of the tree, and we have to come up with
similar strategies for cases where offending nodes are not entire
statements, think of: new A<B>() for instance, where only the type
reference could be malformed. We could then convert it to new A() and tag
it as malformed...

Note that 2.2 introduces some inconsistencies, but since these are tagged
as malformed, clients may prefer these anyway. In a general fashion
malformed nodes do not guarantee much. For instance, you may chose to
traverse them at your own risks.

So 2.1 is more consistent, and 2.2 is more informative.

Maybe clients should speak up a bit ?



                    
                     
                     
          
             Jerome      
                     
                     
     
             Lanneluc/France/I    
                     
                  
             BM@IBMFR      
                     
                     
To 
             Sent by:      
           jdt-core-dev@xxxxxxxxxxx  
         
             jdt-core-dev-admi    
                     
               cc 
             n@xxxxxxxxxxx    
                     
                     
                    
                     
                     
  Subject 
                    
                  Re: [jdt-core-dev]
1.5 source using 
             06/15/2004 10:51    
     a apilevel JLS2          
          
             AM        
                     
                     
       
                    
                     
                     
          
                    
                     
                     
          
             Please respond to    
                     
                  
               jdt-core-dev    
                     
                     
                    
                     
                     
          
                    
                     
                     
          









I would say option 2.2 is no go: you cannot know anything about JLS3 in
a
JLS2 world. Between 2.1 and 2.3, I prefer 2.1 as creating a MALFORMED node
is closer to the spec (see ASTParser#setKind()) and it allows clients to
still traverse the JLS2 nodes. With option 2.3 you end up with a not very
useful parent subtree.

Jerome




             Olivier Thomann
             <Olivier_Thomann@
             ca.ibm.com>    
                     
                     To
             Sent by:      
           jdt-core-dev@xxxxxxxxxxx
             jdt-core-dev-admi    
                     
               cc
             n@xxxxxxxxxxx
                    
                     
                     
  Subject
                    
                  [jdt-core-dev]
1.5 source using a
             06/14/2004 08:11    
     apilevel JLS2
             PM


             Please respond to
               jdt-core-dev







Hi,

Here is the start of a discussion in order to determine what should be
the
resulting tree when a DOM/AST tree is created using a compilation unit
that
contains 1.5 constructs and an api level JLS2. The 1.5 nodes don't exist
in
JLS2. Using JLS3 apilevel, this is not an issue since all new 1.5
constructs are available.

See the attached document and please give us your feedback.



Thanks,

Olivier[attachment "documentfor59052.txt" deleted by Jerome
Lanneluc/France/IBM]

_______________________________________________
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