Home » Modeling » OCL » processing AST, finding out if current parsed part is the body of the OCL expression
processing AST, finding out if current parsed part is the body of the OCL expression [message #901198] |
Fri, 10 August 2012 09:27 |
fv fv Messages: 19 Registered: April 2012 |
Junior Member |
|
|
Hi,
when processing the Abstract Syntax Tree with AbstractVisitor I want to know if the current parsed part is the body of an overlying expression. To make it more clear, I have uploaded an example of a syntax tree. Referring to the example:
when parsing the equality operator a.x = B::MALE (this happens in the overriden handleOperationCallExp()) I want to know if this expression is the body (or source etc.) of another expression (in this case: forAll)
My solution would be to use the predefined function eContaintingFeature() on the current parsed OCL Expression. To find out if the expression is a source, body etc. I would call eContainingFeature() on the expression. In the example above, the output would be:
org.eclipse.emf.ecore.impl.EReferenceImpl@d07f45 (name: body) (ordered: true, unique: true, lowerBound: 0, upperBound: 1) (changeable: true, volatile: false, transient: false, defaultValueLiteral: null, unsettable: false, derived: false) (containment: true, resolveProxies: false)
Then I would look at the value of the attribut "name".
Is this the appropriate way for my intention?
I have searched for the documentation in order to find out which values the name attribut can reach but didn't find something useful. The values I got by testing are the following: body,source, bodyExpression, specification.
Is there are docu or can somebody tell me which values can be reached?
Thanks a lot!
[Updated on: Fri, 10 August 2012 09:29] Report message to a moderator
|
|
|
Re: processing AST, finding out if current parsed part is the body of the OCL expression [message #901205 is a reply to message #901198] |
Fri, 10 August 2012 10:27 |
Ed Willink Messages: 7669 Registered: July 2009 |
Senior Member |
|
|
Hi
If you use the new Xtext Pivot-based OCL, you can experiment in the OCL
Xtext Console.
self.oclType().ownedAttribute() will list all properties.
self.oclContainer() will find the container.
self.oclContainer()->selectByKind(LoopExp)->exists(body = self)
but your query is vague so perhaps just
self.oclContainer().oclIsKindOf(OCLExpression) wil do
If you use the old Ecore binding, similar things can be achieved with
eClass() and eContainer().
Regards
Ed Willink
On 10/08/2012 10:27, fv fv wrote:
> Hi,
>
> when processing the Abstract Syntax Tree with AbstractVisitor I want
> to know if the current parsed part is the body of an overlying
> expression. To make it more clear, I have uploaded an example of a
> syntax tree. Referring to the example:
> when parsing the equality operator a.x = B::MALE (this happens in the
> overriden handleOperationCallExp()) I want to know if this expression
> is the body (or source etc.) of another expression (in this case: forAll)
>
>
> My solution would be to use the predefined function
> eContaintingFeature() on the current parsed OCL Expression. To find
> out if the expression is a source, body etc. I would call
> eContainingFeature() on the expression. In the example above, the
> output would be:
>
> org.eclipse.emf.ecore.impl.EReferenceImpl@d07f45 (name: body)
> (ordered: true, unique: true, lowerBound: 0, upperBound: 1)
> (changeable: true, volatile: false, transient: false,
> defaultValueLiteral: null, unsettable: false, derived: false)
> (containment: true, resolveProxies: false)
>
> Then I would look at the value of the attribut "name".
>
> Is this the appropriate way for my intention?
>
> I have searched for the documentation in order to find out which
> values the name attribut can reach but didn't find something useful.
> The values I got by testing are the following: body,source,
> bodyExpression, specification.
> Is there are docu or can somebody tell me which values can be reached?
>
> Thanks a lot!
|
|
| |
Goto Forum:
Current Time: Tue Sep 17 22:11:24 GMT 2024
Powered by FUDForum. Page generated in 0.04940 seconds
|