anuragraghavan / franca

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

Deployment accessor for types are not polymorphic -> Compiler error #101

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Specify: for structs {IsLockable : Boolean (default:false);} in 
DeploySpec.fdepl
2. Specify: for arrays {IsLockable : Boolean (default:false);} in 
DeploySpec.fdepl

What is the expected output? What do you see instead?

In generated Java class public class DeploySpecInterfacePropertyAccessor
there should be two polymorphic methods:
public Boolean getIsLockable (FCompoundType obj)
public Boolean getIsLockable (FArrayType obj)

But what I get is:
public Boolean getIsLockable (EObject obj)
public Boolean getIsLockable (EObject obj)
This is a general problem, because accessors for all types always use EObject 
instead of the actual type. 

What version of the product are you using? On what operating system?
Franca 0.8.9

Please provide any additional information below.

Original issue reported on code.google.com by Roman.St...@gmail.com on 8 May 2014 at 7:11

GoogleCodeExporter commented 9 years ago
Agreed. In the current implementation, only some Franca types are handled 
specifically by the generated code, many others are generated as EObject 
arguments. The general problem here is that the property hosts in the 
specifications are kind of aspects, which have some overlap by definition. 
E.g., a "for strings" property will also be applied to an FArgument or an 
FAttribute if its type is "String". 

We will do a general analysis of this "aspect-oriented"-like mapping and 
improve the generated code for Franca 0.9.x with x>0. Meanwhile, these 
collisions have to be worked around by avoiding duplicate property names in 
case of a collision in the generated code.

Original comment by klaus.birken@gmail.com on 9 May 2014 at 8:55

GoogleCodeExporter commented 9 years ago
I ran into the same problem today trying to define the same deployment property 
for (almost) all kinds of type definitions.

Your comment worries me a bit, though. If I get you right (and take the inverse 
of your statement) then it is not possible to define a deployment specification 
that only applies to type definitions. However, that is exactly what I was 
trying to do. I do not want to have these deployment specifications to be 
applicable for method parameters, attributes, etc. because they make absolutely 
no sense there. They only make sense in the scope of a type definition.

As an additional note:
There is a "for numbers" specification which applies to both integers and 
floats. In my case it would be handy to have a "for types" specification which 
applies to all type definitions. Then I would no longer have to repeat the 
property for all kinds of types.

Original comment by klaus....@intel.com on 23 May 2014 at 12:01

GoogleCodeExporter commented 9 years ago
I agee deployment specifications to be for method parameters is most probably 
not needed. In fact what I'm activly using is a deployment spec:
   for arguments
   {
      // Hidden means, that the arguments will not be published to the JavaScript API
      // The argument gets resolved in the bridge
      Hidden : Boolean (default:false);
   }

Original comment by Roman.St...@gmail.com on 23 May 2014 at 8:31

GoogleCodeExporter commented 9 years ago

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

GoogleCodeExporter commented 9 years ago
Postponed to 0.9.2.

Original comment by klaus.birken@gmail.com on 18 Dec 2014 at 2:56

GoogleCodeExporter commented 9 years ago
Postponed to 0.9.3.

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

GoogleCodeExporter commented 9 years ago

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