Home » Modeling » TMF (Xtext) » [2.3.1 to 2.6.2] Migrating TypeProvider and Validator(JvmTypeReference vs. LightweightTypeReference)
|
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 |
Sebastian Zarnekow Messages: 3118 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 #1420163 is a reply to message #1419984] |
Tue, 09 September 2014 15:45 |
Sebastian Zarnekow Messages: 3118 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 #1422133 is a reply to message #1421460] |
Fri, 12 September 2014 11:22 |
Sebastian Zarnekow Messages: 3118 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 #1423917 is a reply to message #1422937] |
Mon, 15 September 2014 07:05 |
Sebastian Zarnekow Messages: 3118 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
> }
> }
>
|
|
| |
Goto Forum:
Current Time: Thu Sep 19 00:55:13 GMT 2024
Powered by FUDForum. Page generated in 0.04233 seconds
|