Operator mapping wrong since all the overloaded primitive methods are there [message #778066] |
Wed, 11 January 2012 11:21 |
Ingo Meyer 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 |
Sebastian Zarnekow 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
|
|
|
|
Powered by
FUDForum. Page generated in 0.02945 seconds