Open GoogleCodeExporter opened 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
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
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
Original comment by klaus.birken@gmail.com
on 29 Jul 2014 at 9:41
Postponed to 0.9.2.
Original comment by klaus.birken@gmail.com
on 18 Dec 2014 at 2:56
Postponed to 0.9.3.
Original comment by klaus.birken@gmail.com
on 11 May 2015 at 8:48
Original comment by klaus.birken@gmail.com
on 11 May 2015 at 8:48
Original issue reported on code.google.com by
Roman.St...@gmail.com
on 8 May 2014 at 7:11