Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » [2.3.1 to 2.6.2] Migrating TypeProvider and Validator(JvmTypeReference vs. LightweightTypeReference)
[2.3.1 to 2.6.2] Migrating TypeProvider and Validator [message #1419880] Tue, 09 September 2014 07:58 Go to next message
Ingo Meyer is currently offline Ingo MeyerFriend
Messages: 162
Registered: July 2009
Senior Member
Hi,

I'm starting to migrate our project with a heavily extended Xbase-based DSL to Xtext 2.6 and later 2.7.
So far I have a rough idea what has been changed, but these new LightweightTypeReference eating my hair...
My OwnTypeProvider now extends XbaseWithAnnotationsTypeComputer, but sometimes I have a JvmTypeReference already, but I need to return a LightweightTypeReference. I mean not for XExpressions, so there is no state.
For example my attribute looks like:
Attribute :
	'attr' name = ValidID
	':'
	( typeRef = JvmTypeReference ('(' arguments += XExpression (',' arguments += XExpression)* ')')?
	| 'calc' expr = XExpression
	)
	('{'
		(block = MappingBlock)?
	'}')?
	;


My OwnTypeProvider has a method "LightweightTypeReference getType (Attirbute x)" which is used in Inferrer and Validation, so I need the LightweightTypeReference.
But what if in model typeRef is used, i.e. "attr xyz : java.lang.String". Then I have a JvmTypeReference.
What to return here?

Any help is appreciated...
Thanks
~Ingo
Re: [2.3.1 to 2.6.2] Migrating TypeProvider and Validator [message #1419913 is a reply to message #1419880] Tue, 09 September 2014 08:36 Go to previous messageGo to next message
Sebastian Zarnekow is currently offline Sebastian ZarnekowFriend
Messages: 3104
Registered: July 2009
Senior Member
Hi Ingo,

to obtain a LightweightTypeReference, you have to use the given
ITypeComputationState along with

state.getReferenceOwner().toLightweightTypeReference(jvmTypeRef);

If you're traversing the given expectations (often only one) by means of
state.getExpectations, I'd recommend to use
expectation.getReferenceOwner() ... instead.

Regards,
Sebastian
--
Looking for professional support for Xtext, Xtend or Eclipse Modeling?
Go visit: http://xtext.itemis.com

Am 09.09.14 09:58, schrieb Ingo Meyer:
> Hi,
>
> I'm starting to migrate our project with a heavily extended Xbase-based
> DSL to Xtext 2.6 and later 2.7.
> So far I have a rough idea what has been changed, but these new
> LightweightTypeReference eating my hair...
> My OwnTypeProvider now extends XbaseWithAnnotationsTypeComputer, but
> sometimes I have a JvmTypeReference already, but I need to return a
> LightweightTypeReference. I mean not for XExpressions, so there is no
> state.
> For example my attribute looks like:
>
> Attribute :
> 'attr' name = ValidID
> ':'
> ( typeRef = JvmTypeReference ('(' arguments += XExpression (','
> arguments += XExpression)* ')')?
> | 'calc' expr = XExpression
> )
> ('{'
> (block = MappingBlock)?
> '}')?
> ;
>
>
> My OwnTypeProvider has a method "LightweightTypeReference getType
> (Attirbute x)" which is used in Inferrer and Validation, so I need the
> LightweightTypeReference.
> But what if in model typeRef is used, i.e. "attr xyz :
> java.lang.String". Then I have a JvmTypeReference.
> What to return here?
>
> Any help is appreciated...
> Thanks
> ~Ingo
Re: [2.3.1 to 2.6.2] Migrating TypeProvider and Validator [message #1419984 is a reply to message #1419913] Tue, 09 September 2014 10:45 Go to previous messageGo to next message
Ingo Meyer is currently offline Ingo MeyerFriend
Messages: 162
Registered: July 2009
Senior Member
Hi Sebastian,

yes, that helps with computing an XExpression. But outisde the TypeComputer I do not have the ITypeComputationState , right?
My method should return the type of the Attribute model element (same then in Domainmodel example) and this is not a XExpression.
My method is in an Helper class with the exact signiture "public LightweightTypeReference getType (Attribute x)". This is used i.e. in my Validator to validate the attribute type. The XbaseValidator needs LightweightTypeReferences.
To further explain here is the implementation:
	public LightweightTypeReference getType(
			Attribute x )
	{
		if (x.getExpr() != null)
			return typeResolver.resolveTypes( x ).getActualType( x.getExpr() ); // this is ok
		else if (x.getTypeRef() != null)
			return x.getTypeRef(); // here is the problem
	}

The second return's getTypeRef is already a JvmTypeReference. So what to do there?
Or can I pass the Attribute itself to the TypeResolver, even if it is not an XExpression? If yes, where to put the code?
Re: [2.3.1 to 2.6.2] Migrating TypeProvider and Validator [message #1420163 is a reply to message #1419984] Tue, 09 September 2014 15:45 Go to previous messageGo to next message
Sebastian Zarnekow is currently offline Sebastian ZarnekowFriend
Messages: 3104
Registered: July 2009
Senior Member
Am 09.09.14 12:45, schrieb Ingo Meyer:
> Hi Sebastian,
>
> yes, that helps with computing an XExpression. But outisde the
> TypeComputer I do not have the ITypeComputationState , right?
> My method should return the type of the Attribute model element (same
> then in Domainmodel example) and this is not a XExpression.
> My method is in an Helper class with the exact signiture "public
> LightweightTypeReference getType (Attribute x)". This is used i.e. in my
> Validator to validate the attribute type. The XbaseValidator needs
> LightweightTypeReferences.
> To further explain here is the implementation:
>
> public LightweightTypeReference getType(
> Attribute x )
> {
> if (x.getExpr() != null)
> return typeResolver.resolveTypes( x ).getActualType(
> x.getExpr() ); // this is ok
> else if (x.getTypeRef() != null)
> return x.getTypeRef(); // here is the problem
> }
>
> The second return's getTypeRef is already a JvmTypeReference. So what to
> do there?
> Or can I pass the Attribute itself to the TypeResolver, even if it is
> not an XExpression? If yes, where to put the code?
>

In your helper, you could something like this:

@Inject
CommonTypeComputationServices services

ITypeReferenceOwner owner = new StandardTypeReferenceOwner(services,
someResourceSet);
OwnedConverter converter = new OwnedConverter(owner);
LightweightTypeReference result =
converter.toLightweightTypeReference(someJvmTypeReference);

With 2.7, you could ask the owner directly to obtain a
LightweightTypeReference.

Regards,
Sebastian
--
Looking for professional support for Xtext, Xtend or Eclipse Modeling?
Go visit: http://xtext.itemis.com
Re: [2.3.1 to 2.6.2] Migrating TypeProvider and Validator [message #1421460 is a reply to message #1420163] Thu, 11 September 2014 11:55 Go to previous messageGo to next message
Ingo Meyer is currently offline Ingo MeyerFriend
Messages: 162
Registered: July 2009
Senior Member
Thanks Sebastian, that helped a lot to dive further into the new Xtext!
Two more questions:

Is it correct that I need to handle ALL expressions in the inferrer to get them resolved in the TypeComputer?

In my TypeComputer I need the annotations of an JvmOperation which is not yet resolved. How can I achive that the expression is computer later, when the JvmOperation is resolved?

Thanks
Ingo
Re: [2.3.1 to 2.6.2] Migrating TypeProvider and Validator [message #1422133 is a reply to message #1421460] Fri, 12 September 2014 11:22 Go to previous messageGo to next message
Sebastian Zarnekow is currently offline Sebastian ZarnekowFriend
Messages: 3104
Registered: July 2009
Senior Member
Hi Ingo,

yes, the common way to do things is to put all expressions into a JVM
context. That could be a method / constructor body, field initializer or
annotation value. Things become messy if you have dangling expressions
somewhere.
If your operation uses an inferred return type, you can use
JvmTypesBuilder.inferredType(XExpression) which will produce a
JvmTypeReference that'll trigger computation on demand.
Usually there is nothing else that has to be done to solve the problem
with yet unresolved operations.

Regards,
Sebastian
--
Looking for professional support for Xtext, Xtend or Eclipse Modeling?
Go visit: http://xtext.itemis.com

Am 11.09.14 13:55, schrieb Ingo Meyer:
> Thanks Sebastian, that helped a lot to dive further into the new Xtext!
> Two more questions:
>
> Is it correct that I need to handle ALL expressions in the inferrer to
> get them resolved in the TypeComputer?
>
> In my TypeComputer I need the annotations of an JvmOperation which is
> not yet resolved. How can I achive that the expression is computer
> later, when the JvmOperation is resolved?
>
> Thanks
> Ingo
>
Re: [2.3.1 to 2.6.2] Migrating TypeProvider and Validator [message #1422937 is a reply to message #1422133] Sat, 13 September 2014 16:59 Go to previous messageGo to next message
Ingo Meyer is currently offline Ingo MeyerFriend
Messages: 162
Registered: July 2009
Senior Member
Hi Sebastian,

my proxy is still unresolved (XMemberFeatureCall.feature). It is an operation to static function extension. In the editor the operation is shown correct and F3 brings me to the correct Java method.
In my old 2.3 version I always used the LinkingAssumptions in my ScopeProvider for unresolved features.
Here I have no clue.
The XMemberFeatureCall is inside an own XExpression element. I extended XBase with a XSQLSelectElement
	'select'
	( distinct ?= 'distinct'
	| all ?= 'all'
	)?
	( '*'
	| (selects += XExpression (',' selects += XExpression)*)
	)?
	'from' from = XExpression
	(=> 'as' name = ID)?
	...

and inside the first select there is a call to "p.attribute.sum", where "p" is the XSQLSelectElement (is extends JvmIdentifiableElement) and "attribute" is a feature of an own entity (like in DomainModel) of type Double.

select p.attribute.sum from entity as p


"sum" is an imported extension:
	@AggregateFunction
	public static <T extends Number> T sum(
			final T field )
	{
		throw new UnsupportedOperationException( "Should have been replaced!" );
	}

For computing the return type of my XSQLSelectElement I need the "@AggregateFunction", but the p.attribute.feature is a proxy!
(Return type is not a collection for aggregate functions Smile)

This is my check code:
	def boolean isAggregateFunction (XExpression x) {
		switch x {
			// must come before XAbstractFeatureCall ;-)
			XBinaryOperation			: x.leftOperand.isAggregateFunction && x.rightOperand.isAggregateFunction
			XAbstractFeatureCall		: x.getAggregateFunction != null
			XAbstractFunctionAggregate	: true
			default						: false
		}
	}
	
	def JvmOperation getAggregateFunction (XExpression x) {
		switch x {
			XMemberFeatureCall :
				switch f : x.feature { // <= this is unresolved
					JvmOperation :
						for (ref : f.annotations)
							if (typing.is( ref.annotation, typeof( AggregateFunction ) ))
								return f
				}
			default : null
		}
	}
Re: [2.3.1 to 2.6.2] Migrating TypeProvider and Validator [message #1423917 is a reply to message #1422937] Mon, 15 September 2014 07:05 Go to previous messageGo to next message
Sebastian Zarnekow is currently offline Sebastian ZarnekowFriend
Messages: 3104
Registered: July 2009
Senior Member
Hi Ingo,

please try to avoid to use #getFeature() from within the type
computation. The feature is likely to be unset. Please explore
state#getLinkingCandidates instead. It's similar yet more powerful than
the former linking assumptions.
Also please note that type inference should usually follow the control
flow, e.g. for your select-like expression, you'd generally first infer
the from-expression and the selects.

Regards,
Sebastian
--
Looking for professional support for Xtext, Xtend or Eclipse Modeling?
Go visit: http://xtext.itemis.com

Am 13.09.14 18:59, schrieb Ingo Meyer:
> Hi Sebastian,
>
> my proxy is still unresolved (XMemberFeatureCall.feature). It is an
> operation to static function extension. In the editor the operation is
> shown correct and F3 brings me to the correct Java method.
> In my old 2.3 version I always used the LinkingAssumptions in my
> ScopeProvider for unresolved features.
> Here I have no clue.
> The XMemberFeatureCall is inside an own XExpression element. I extended
> XBase with a XSQLSelectElement
>
> 'select'
> ( distinct ?= 'distinct'
> | all ?= 'all'
> )?
> ( '*'
> | (selects += XExpression (',' selects += XExpression)*)
> )?
> 'from' from = XExpression
> (=> 'as' name = ID)?
> ...
>
> and inside the first select there is a call to "p.attribute.sum", where
> "p" is the XSQLSelectElement (is extends JvmIdentifiableElement) and
> "attribute" is a feature of an own entity (like in DomainModel) of type
> Double.
>
>
> select p.attribute.sum from entity as p
>
>
> "sum" is an imported extension:
>
> @AggregateFunction
> public static <T extends Number> T sum(
> final T field )
> {
> throw new UnsupportedOperationException( "Should have been
> replaced!" );
> }
>
> For computing the return type of my XSQLSelectElement I need the
> "@AggregateFunction", but the p.attribute.feature is a proxy!
> (Return type is not a collection for aggregate functions :))
>
> This is my check code:
>
> def boolean isAggregateFunction (XExpression x) {
> switch x {
> // must come before XAbstractFeatureCall ;-)
> XBinaryOperation :
> x.leftOperand.isAggregateFunction && x.rightOperand.isAggregateFunction
> XAbstractFeatureCall : x.getAggregateFunction != null
> XAbstractFunctionAggregate : true
> default : false
> }
> }
>
> def JvmOperation getAggregateFunction (XExpression x) {
> switch x {
> XMemberFeatureCall :
> switch f : x.feature { // <= this is unresolved
> JvmOperation :
> for (ref : f.annotations)
> if (typing.is( ref.annotation, typeof(
> AggregateFunction ) ))
> return f
> }
> default : null
> }
> }
>
Re: [2.3.1 to 2.6.2] Migrating TypeProvider and Validator [message #1423955 is a reply to message #1423917] Mon, 15 September 2014 08:26 Go to previous message
Ingo Meyer is currently offline Ingo MeyerFriend
Messages: 162
Registered: July 2009
Senior Member
Yes, the "state.getLinkingCandidates" does it!

Many thanks,
Ingo
Previous Topic:Xtext imports
Next Topic:[shameless plug] MDD-related conference in .nl
Goto Forum:
  


Current Time: Tue Dec 10 07:55:13 GMT 2019

Powered by FUDForum. Page generated in 0.02278 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top