search

KoheAsano / franca

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

Remove string constants from enumerations #52

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
In Franca it is possible to define enum´s using non-numeric constants, e.g.:

enumeration MyEnum {
        E_UNKNOWN = "0"
        E_OK = "0x01"
        E_STRINGVALUE = "mystringvalue"
        E_FLOATVALUE = "42,31415"
}

In this example E_STRINGVALUE contains a non-numeric value.
It is not possible to use this enum definition in C++ or D-Bus or transform 
this to FIBEX, because in all these environments enums are specified as 
numerical values.

Another argument is that also other data types like float constants could be 
expected. It is unspecified what Franca expects from a specification like 
E_FLOATVALUE: is this to be handled as a string, float, double or cut down to 
an integer?

For any implementation it is a requirement to have a stable, static, compile 
time definition of enum data types, so it is critical if any new strange enum 
value could completely conflict with prior versions (e.g. if a string value is 
added to an enum only containing integer constants).

Propose to remove string support for Franca enums completely and restrict to 
numeric integer constants only.

Original issue reported on code.google.com by manfred....@bmw.de on 2 Jul 2013 at 3:25

GoogleCodeExporter commented 9 years ago 
This is an API-breaking change. We will change the String-type default values 
to integer and hex values. The options for defining defaults (integer, hex, 
maybe more in future) are provided as part of the IDL syntax only. IN the model 
API there will be just an integer constant without additional information about 
how it has been specified in the IDL.

In order to avoid additional work in downstream generators, we won't provide a 
deprecation phase. This will require downstream tools to adapt to this change 
exactly once.

Original comment by klaus.birken@gmail.com on 28 Aug 2013 at 9:55

GoogleCodeExporter commented 9 years ago 
for code generation it would make sense to have the number system used for 
constant definition available from the model. Goal is to enable code generators 
or transformations to put numbers in exactly the same way to their output as it 
was specified in Franca, e.g. hexadecimal, decimal, binary or octal.

Original comment by manfred....@bmw.de on 28 Aug 2013 at 1:28

GoogleCodeExporter commented 9 years ago

Original comment by klaus.birken@gmail.com on 19 Feb 2014 at 10:33

GoogleCodeExporter commented 9 years ago 
Finished implementation by commit 5ea396c on develop. 

We decided in favor of a deprecation phase, i.e., string values are still 
supported, but will be marked with deprecation warnings by the validator. This 
allows a smooth transition for existing fidl files. The deprecation phase will 
end with release 0.9.1 or later (not defined yet).

We extended the requirements a bit: It is possible to use arbitrary expressions 
to define an enumerator value. The same syntax can be used as for initializer 
expressions of constant definitions. This is a quite powerful feature. However, 
it is currently not possible to define one enumerator's value by means of 
another enumerator, because there is no implicit conversion from enum types to 
integer types.

Hint for code generator developers: This change breaks your API. There are two 
helper functions which should be used to determine the value of an enumerator, 
both in class org.franca.core.utils.ExpressionEvaluator:
- evaluateInteger() can be used for evaluating an e.value. If the deprecated 
string syntax is used for the enumerator's value, this function will return null
- evaluateIntegerOrParseString() can also be used for evaluating an e.value. 
This supports the deprecated string syntax, including strings which represent 
hex numbers (e.g., "0xAB).

Regarding comment #2: If the code generator wants to generate code exactly as 
specified in Franca (and not evaluated to an atomic constant), the evaluator 
shouldn't be used, but the expression has to be parsed instead. But this might 
be tricky (look at the implementation of ExpressionEvaluator to get an 
impression). In that case, it might be a good solution to fall back to the 
evaluator if the expression is beyond a defined complexity.

Current scope restriction: Hex numbers cannot be used in the enumerator value 
expressions yet. Support of hex values is a separate issue which will be 
supported in any kind of Franca expression.

Original comment by klaus.birken@gmail.com on 21 Feb 2014 at 9:38

GoogleCodeExporter commented 9 years ago

Original comment by klaus.birken@gmail.com on 21 Feb 2014 at 9:38

GoogleCodeExporter commented 9 years ago 
Integrated to master.

Original comment by klaus.birken@gmail.com on 4 Mar 2014 at 12:17

GoogleCodeExporter commented 9 years ago

Original comment by klaus.birken@gmail.com on 25 Jan 2015 at 12:29