anuragraghavan / franca

Automatically exported from code.google.com/p/franca
0 stars 0 forks source link

Method deployments cannot handle overloaded methods #116

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Create a deployment model specification which defines a mandatory property 
for methods.
2. Create an interface specification with multiple overloads of the same method.
3. Create a deployment for the interface specification.

What is the expected output?
The deployment model contains property definitions for all overloads and has no 
validation errors.

What do you see instead?
The overloaded method can only be deployed once in the deployment model. 
Additionally, the validation (correctly) complains about the missing overloads 
of the method.

What version of the product are you using? On what operating system?
Franca 0.9.0 on Linux

Please provide any additional information below.
- The same holds true for overloaded broadcasts.
- I assume (but have not tested) that if you define an optional property for 
methods in the deployment model specification the actual method that is 
deployed is random (i.e. no specific overload can be selected explicitly).

Original issue reported on code.google.com by klaus....@intel.com on 23 Jun 2014 at 3:09

GoogleCodeExporter commented 9 years ago

Original comment by klaus.birken@gmail.com on 29 Jul 2014 at 9:43

GoogleCodeExporter commented 9 years ago
This is an issue for CommonAPI and e.g. SomeIP language binding too, because 
SomeIP uses a method id for referral to remote method calls, which need to be 
defined in a Franca deployment. Of course it makes no sense to have the same 
method id for all Franca methods with same name in case of method overloading.

Original comment by manfred....@bmw.de on 11 Aug 2014 at 2:58

GoogleCodeExporter commented 9 years ago
solution proposal:
this problem could be solved if it would be possible to add an "id" to the 
Franca IDL method definitions, which could be unique even in case of method 
overloading.
The id could be used as reference from the deployment model to the method 
instead of the method name.

Original comment by manfred....@bmw.de on 12 Aug 2014 at 3:16

GoogleCodeExporter commented 9 years ago
The proposal with the added "id" seems to be feasible. However, an alternative 
solution would be to specify the signature of the methods (because this is the 
actual difference between the method definitions). However, it is not clear how 
this could be done in detail. We have to analyse this further.

Original comment by klaus.birken@gmail.com on 10 Nov 2014 at 12:18

GoogleCodeExporter commented 9 years ago
Implemented on develop with commit 779a4f6.

Use *selectors* when defining overloaded methods and broadcast, e.g.

    method m1:a {
        in { UInt8 a }
    }
    method m1:b {
        in { String a }
    }

Method m1 is overloaded, but each of the overloaded method can be referenced 
explicitly by using its name "m1" including the selector "a" or "b", 
respectively. Selectors might be arbitrary IDs.

Original comment by klaus.birken@gmail.com on 11 May 2015 at 8:46