Bug 489544 - Have polymorphism management with service: interpreter
Summary: Have polymorphism management with service: interpreter
Status: NEW
Alias: None
Product: Sirius
Classification: Modeling
Component: Core (show other bugs)
Version: 3.1.0   Edit
Hardware: PC Linux
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Project inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2016-03-14 09:45 EDT by Esteban DUGUEPEROUX CLA
Modified: 2016-03-14 10:06 EDT (History)
1 user (show)

See Also:


Attachments
Sample project to reproduce (8.68 KB, application/zip)
2016-03-14 10:06 EDT, Esteban DUGUEPEROUX CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Esteban DUGUEPEROUX CLA 2016-03-14 09:45:45 EDT
From AQL we can call Java service. And with 2 Java methods with same signature having only parameter type difference, i.e. one method parameter is a subType of the second method parameter, we have the second method called when passing a instance of the subType. With service: interpreter there is no polymorphism feature, then only the first Java method will be called.

This bugzilla is a feature request to have a homonogeous behavior on Java service call between AQL and service: interpreters.
Comment 1 Pierre-Charles David CLA 2016-03-14 09:51:26 EDT
Maybe we could reuse the same logic as the one used by AQL itself in AbstractService.isLowerOrEqualParameterTypes(). It seems slef-contained enough that we could copy and adapt it (its from AQL, part of Acceleo, so no IP/licensing issue).
Comment 2 Esteban DUGUEPEROUX CLA 2016-03-14 10:06:14 EDT
Created attachment 260279 [details]
Sample project to reproduce

Scenario to reproduce:

1. Import the attached project
2. Open the diagram and see "EClass label : c1" for the EClass and "ENamedElement label : p1" for the EPackage, here we have polymorphism because the label expression use "aql:self.getLabel()"
3. Now update the odesign to have "service:getLabel()" as label expression for both mappings and save
4. Switch to the diagram editor and see the result of refresh : "ENamedElement label : c1" for the EClass and "ENamedElement label : p1" for the EPackage, here we see that we don't have polymorphism with service: interpreter.