Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » Operator mapping wrong since all the overloaded primitive methods are there
Operator mapping wrong since all the overloaded primitive methods are there [message #778066] Wed, 11 January 2012 11:21 Go to next message
Ingo Meyer is currently offline Ingo MeyerFriend
Messages: 162
Registered: July 2009
Senior Member
Hi,

since all those overloaded methods are added to e.g. IntegerExtensions I have massive problems with wrongly choosen overloaded methods.
I don't know if this is my mistake or if it is a problem of Xtext.

Please try the following example to test, for example in the domainmodelexample in any entity:
op testLiteralsOperator
{
	var ^ok = 0			
	^ok = ^ok + 1
	
	val ^sec = 30000 			
	Thread::sleep( ^sec * 1000 )
}


For me the scoped "+" operator will be this one:
"double org.eclipse.xtext.xbase.lib.IntegerExtensions.operator_plus(int a, double b)"

As far as I figured out the TypeProvider will be asked during scoping for all overloaded methods "operator_plus" 2nd argument (double, float, int, ...) and gets a rawExpectation of that type.
But for literals like in my example the rawExpectation is not evaluated for primitives (ok, mostly the primitives are type-compatible) and just the literals Java value is returned.

But the problem is in the generated code:
{
	int ok = 0;
	double _operator_plus = IntegerExtensions.operator_plus( ok, 1 );
	ok = _operator_plus;
	final int sec = 30000;
	double _operator_multiply = IntegerExtensions.operator_multiply( sec, 1000 );
	Thread.sleep( _operator_multiply );
}


As you see here the return type is "double" which comes from the scoped method. but Java does just see ok (int) and 1 (int) here and chooses the (int, int) version of the method. Subsequently the assignment "ok = _operator_plus" is wrong!

Similar is with the "sleep" method.

Is it because the BestMatchingJvmFeatureScope will return the first OK result, but not the "best match" as the name implies???

Or can it be a mistake somewhere in my code?

Can somebody please check my example.

Thanks in advance,
Ingo
Re: Operator mapping wrong since all the overloaded primitive methods are there [message #778125 is a reply to message #778066] Wed, 11 January 2012 12:52 Go to previous messageGo to next message
Sebastian Zarnekow is currently offline Sebastian ZarnekowFriend
Messages: 3118
Registered: July 2009
Senior Member
Hi Ingo,

please file a ticket.

Thanks,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com

Am 11.01.12 12:21, schrieb Ingo Meyer:
> Hi,
>
> since all those overloaded methods are added to e.g. IntegerExtensions I
> have massive problems with wrongly choosen overloaded methods.
> I don't know if this is my mistake or if it is a problem of Xtext.
>
> Please try the following example to test, for example in the
> domainmodelexample in any entity:
>
> op testLiteralsOperator
> {
> var ^ok = 0
> ^ok = ^ok + 1
>
> val ^sec = 30000
> Thread::sleep( ^sec * 1000 )
> }
>
>
> For me the scoped "+" operator will be this one:
> "double org.eclipse.xtext.xbase.lib.IntegerExtensions.operator_plus(int
> a, double b)"
>
> As far as I figured out the TypeProvider will be asked during scoping
> for all overloaded methods "operator_plus" 2nd argument (double, float,
> int, ...) and gets a rawExpectation of that type.
> But for literals like in my example the rawExpectation is not evaluated
> for primitives (ok, mostly the primitives are type-compatible) and just
> the literals Java value is returned.
>
> But the problem is in the generated code:
>
> {
> int ok = 0;
> double _operator_plus = IntegerExtensions.operator_plus( ok, 1 );
> ok = _operator_plus;
> final int sec = 30000;
> double _operator_multiply = IntegerExtensions.operator_multiply( sec,
> 1000 );
> Thread.sleep( _operator_multiply );
> }
>
>
> As you see here the return type is "double" which comes from the scoped
> method. but Java does just see ok (int) and 1 (int) here and chooses the
> (int, int) version of the method. Subsequently the assignment "ok =
> _operator_plus" is wrong!
>
> Similar is with the "sleep" method.
>
> Is it because the BestMatchingJvmFeatureScope will return the first OK
> result, but not the "best match" as the name implies???
>
> Or can it be a mistake somewhere in my code?
>
> Can somebody please check my example.
>
> Thanks in advance,
> Ingo
Re: Operator mapping wrong since all the overloaded primitive methods are there [message #778132 is a reply to message #778125] Wed, 11 January 2012 13:06 Go to previous message
Ingo Meyer is currently offline Ingo MeyerFriend
Messages: 162
Registered: July 2009
Senior Member
Done: https://bugs.eclipse.org/bugs/show_bug.cgi?id=368335

I've decided for major importance since this is one of my current main problems with Xbase.
Previous Topic:[xtend2] java enums
Next Topic: Xtext grammar generated from ECORE
Goto Forum:
  


Current Time: Sat Apr 20 00:17:43 GMT 2024

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

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

Back to the top