dimensions: (none, interesting because there is one dimension, but nothing specific in it)
                                                                                initializer: ArrayInitializer
                                                                                        expressions:
                                                                                                PrefixExpression(-2)
                                                                                                NumberLiteral(3)
new int[][] { { 2 , -3 } , { 4 , 5 } }                        ArrayCreation:
                                                                                type: ArrayType(int[][])
                                                                                initializer: ArrayInitializer
                                                                                        expressions:
                                                                                                ArrayInitializer(NumberLiteral(2), PrefixExpression(-3))
                                                                                                ArrayInitializer(NumberLiteral(4), NumberLiteral(5))
new org.eclipse.jem.tests.proxy.initParser.NavigationParameters(new int[][] {{1,2,3},{3,4,5}})
                                                                        ClassInstanceCreation (std)
                                                                                arguments: ArrayCreation (std)
new int[3][]                                                        ArrayCreation:
                                                                                type: ArrayType(int[][])
                                                                                dimensions: NumberLiteral(3)
new org.eclipse.jem.tests.proxy.initParser.NavigationParameters().set(false, false)                
                                                                        MethodInvocation:
                                                                                expression: ClassInstanceCreation(std)
                                                                                name: set
                                                                                arguments: 2 BooleanLiterals

So here's the list of used ASTNodes. Expression, StringLiteral, MethodInvocation, SimpleName, QualifiedName, NumberLiteral, CharacterLiteral, ClassInstanceCreation, NullLiteral, CastExpression, PrimitiveType, PrefixExpression, AnonymousClassDeclaration, ParenthesizedExpression, ArrayCreation, ArrayType, and ArrayInitializer.

SimpleName/QualifiedName: I don't see a need for us to distinquish between the two in our nodes. The bigger problem is that we get these, except for method name, in place of a class name. What really want for these is Type. So I think we don't need Simple/QualifiedName at all. Just a string attribute for MethodInvocation method name is sufficient. And all of the other uses we want a TypeLiteral instead.

ParenthesizedExpression: We don't need this for allocation purposes, but code gen would require it so that the parenthesis can be added to the generated code. It's not needed for allocation because the expression it wraps is already singled out in the node. But the parenthesis are important for the code so that the wrapped expression can be deduced correctly.

PrefixExpression: Aren't needed when dealing with just number literals and plus/minus, like -10, but they are needed if we intend to deal with expressions like - (3+4). There are also these kinds of prefix operations: (+, -, ++, --, ~,  and !). "++" and "--"  are problematic because they need to work against primitive variables. I don't think we can currently support this concept because that puts in a severe order dependency and we don't have the concept of a primitive variable where the object itself can be changed (i.e. assignment, other than the original assignment making it a part). My suggestion is that on parsing that PrefixExpressions that have a number literal as the operand and operations of plus or minus, that it just gets turned into a NumberLiteral with the plus/minus attached to the literal. This will be easier to read the xmi and to process since the number converters already can handle plus/minus as part of the string. I would leave "~" and "!" and leave it as prefix expression even if the operand is a literal. That is because even though we could easly turn the operand into the appropriate literal, we actually need to know the operation for code generation purposes (i.e. if it was "~0x00", then we shouldn't change it to "0xff" even though they are equivalent because codegeneration would then put out "0xff". And this could make it harder to read because the first form is often used in bit flags and it makes it clearer what bits are being affected).

PrimitiveType/Type/ArrayType: Not sure if we need to distinquish between the three. Need to see what it looks like if we don't and then add back in if we do. This is because for codegen, the string describing the type is sufficient, same for allocation. We can easily tell the difference just from the string. In fact we know exactly where Types need to show and we can simply use EMF string attributes instead. Type's will never be an expression.

TypeLiteral: However a type literal is different. This is something like get(XYZ.class). In here XYX.class is an expression, so the whole thing is a TypeLiteral. We haven't used that as a testcase, but we should allow it.

AnonymousDeclaration: This is a tuffy. We didn't actually support this, we just recognized it and didn't allow it. This was to distinquish from some generic too complicated msg. Need to think about this. It's not even really an expression, it just occur inside of an expression, so we may see it.

Here are the nodes of interest that we currently don't handle: ArrayAccess, Assignment, ConditionalExpression, FieldAccess, InfixExpression (e.g. 4 + 3), InstanceOfExpression, PostFixExpression, SuperFieldAccess, SuperMethodInvocation, ThisExpression, VariableDeclarationExpression. These are all expressions. There are also statements and declarations.

For the other expressions, I don't think we can handle, at least for now:

Assignment: This is of the form  (3 + (x =4)). For the same reason we can't handle ++x. We may want to allow it but only enable the expression evaluation on the right and ignore the 'x=' part. None of our property editors or palette entries would probably ever create something of this form. Though it may come in from parsing the code. One possibility is that on parsing the code, the Assignment expression is turned into just the expression that is on the right. We won't be roundtripping of the code, any changes from the model side will create an entire new expression which won't include the assignment.

PostFixExpression: Because this is of type x++ For the same reason we can't handle ++x.
SuperFieldAccess: This is of the form super.XYZ. Not sure how we can handle this.
SuperMethodInvocation: This is of the form super.xyz(). Not sure how we can handle this.
VariableDeclationExpression: Not necessary to handle. This only occurs in for() statements and since we don't process those.

---------------------------------------------------------------------------

Some changes from the previous note are:

• We have a special expression node called "InvalidExpression". This will be used with a message in it whenever the expression is too complicated. Yup, we still can get too complicated expressions. Though they can be parsed, there is no way for us to evaluate them. For example an anonymous declaration.
• We're not supporting anonymous declaration. Instead, if this is seen during AST conversion we will create an InvalidExpression with a message that we don't handle anonymous classes.
• We created an expression node called "Name". This is used in place of SimpleName and QualifiedName. Turns out we still need these because they can show up as expressions.
• Types aren't a separate node. Turns out wherever a type was required was spelled out explicitly and we could simply use an EMF string attribute instead as the type. We already have code that is smart enough to take a string and figure out quickly if it is a primitive, class, or array class.