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

[Olivier Thomann <Olivier_Thomann@xxxxxxxxxx>]

We could also see this case (converting
1.5 source code into a DOM/AST JLS2 tree) as an error case. The clients
should use a api level that is appropriate. 1.5 constructs cannot be represented
in JLS2 api level. Therefore this is an error case. The resulting tree
will always be incomplete and contain malformed nodes.
So the question is: Dop we really need
to return a tree in such cases? Even if we could use subparts of the tree
that are JLS2 specific, the whole tree is useless.

So we would have the following chart:

Source level       |
    api level
           
             |  JLS2    
  |   JLS3
------------------------------------------
  >= 1.5      
       |    ERROR |     OK
  < 1.4      
         |      OK    
 |     OK

This case would be an error as soon
as the source contains a 1.5 specific construct. Otherwise it would be
ok and in fact the source 1.5 is not required. The problem right now is
that the API is not supporting this error case. It always assumes that
the source can be represented whatever the api level is. 

What do you think?

Olivier

Martin Aeschlimann <martin_aeschlimann@xxxxxxxxxx>
Sent by: jdt-core-dev-admin@xxxxxxxxxxx

06/15/2004 06:10 AM

Please respond to
jdt-core-dev

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

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