_expression_: ClassInstanceCreation (standard
type like we have above)
name:
SimpleName(setElemAt)
arguments:
(StringLiteral and NumberLiteral)
new String[2]
ArrayCreation:
type: ArrayType
componentType:
SimpleName(String)
dimensions:
1 (i.e. how many [] are there)
dimensions: NumberLiteral(2) (i.e. the value
filled into each [])
new String[2][2]
ArrayCreation
type: ArrayType
componentType:
ArrayType
componentType: SimpleName(String)
dimensions: 1
dimensions:
2
dimensions: 2 NumberLiterals.
new int[] {-2,3}
ArrayCreation
type: ArrayType
componentType:
PrimitiveType(int)
dimensions:
1
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.
My next note will be a UML diagram of
the suggested parse allocation tree model.
Thanks,
Rich
