Closed eclipse-ocl-bot closed 1 month ago
eclipse-ocl-bot
commented
1 month ago By Ed Willink on Feb 25, 2013 09:20
Rigorous testing of the code generator was introduced after Juno and revealed that the examples code was only viable for simple OCL. If you use the Kepler M5 milestone that should be installable on Juno, you should find code generation is much improved.
eclipse-ocl-bot
commented
1 month ago By Ed Willink on Feb 27, 2013 15:44
(In reply to comment #0)
I'm not sure which is the correct binding
It's not specified. The environment inheritance rules are missing from Clause 12. In the absence of specification, Java can be used to provide clues as to what might be sensible.
Java parameters occlude fields so I would expect "e" to be the function parameter.
I am using OCL to define operation bodies in my ecore models. I have been using delegation for runtime interpretation of the bodies. Recently I switched to using generate Java code in xxxBodies and have detected an inconsistency between the two.
The hover text in the current editor shows that e is resolving to the function parameter, so I would be surprised if something weird happened downstream.
I recall fixing problems in this area. Would you like to try a recent build from http://www.eclipse.org/modeling/mdt/downloads/?project=ocl. I'll try to get an I-build done this evening.
Probably fixed.
eclipse-ocl-bot
commented
1 month ago By Ed Willink on Jun 17, 2014 05:27
(In reply to Ed Willink from comment #2)
The hover text in the current editor shows that e is resolving to the function parameter
Probably fixed.
test_cg_name_occlusion_401692 demonstrates same behaviour with interpreted and code generated execution.
So in the absence of further comment:
Fixed long ago.
| --- | --- | | Bugzilla Link | 401692 | | Status | RESOLVED FIXED | | Importance | P3 normal | | Reported | Feb 25, 2013 08:10 EDT | | Modified | Jun 17, 2014 05:27 EDT | | Version | 3.2.0 | | Reporter | Andy Carpenter |
Description
I am using OCL to define operation bodies in my ecore models. I have been using delegation for runtime interpretation of the bodies. Recently I switched to using generate Java code in xxxBodies and have detected an inconsistency between the two.
For the model below, runtime delegation binds the variable e in the select operation to the operation parameter, whereas, the Java code generation in xxxBodies binds this variable to the property of the A class.
I'm not sure which is the correct binding, but I would expect the two cases to be consistent.
package scope = 'abc'\ {\ class A\ {\ attribute d : String;\ attribute e : String;\ }\ class B\ {\ operation findA(e : String) : A[?]\ {\ body:\ let found : OrderedSet(A) = as->select(a : A | a.d = e) in if found->size() > 0 then found->first() else null endif;\ }\ property as : A[*] { ordered composes };\ }\ }