You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
"The first enum field shall always use the suffix UNKNOWN. The second enum field shall always use the suffix OTHER."
This requirement, especially the presence of the "UNKNOWN" field is not useful for some enums with technical context - there are cases where it is correct to have a clearly defined default value, using the suffix "DEFAULT = 0" as first entry.
After discussion in the sensors modelling group, we concluded that UNKNOWN should not be used here, and DEFAULT should be the first field.
Also: shorten the lines again, restore old documentation comments
see also discussion on the enum guidelines: OpenSimulationInterface/osi-documentation#68
Signed-off-by: RIFJo <jochmann@rt.rif-ev.de>
pmai
pushed a commit
to RIFJo/open-simulation-interface
that referenced
this issue
Apr 16, 2023
After discussion in the sensors modelling group, we concluded that UNKNOWN should not be used here, and DEFAULT should be the first field.
Also: shorten the lines again, restore old documentation comments
see also discussion on the enum guidelines: OpenSimulationInterface/osi-documentation#68
Signed-off-by: RIFJo <jochmann@rt.rif-ev.de>
The enum naming conventions have rules for required fields.
"The first enum field shall always use the suffix UNKNOWN. The second enum field shall always use the suffix OTHER."
This requirement, especially the presence of the "UNKNOWN" field is not useful for some enums with technical context - there are cases where it is correct to have a clearly defined default value, using the suffix "DEFAULT = 0" as first entry.
discussions here
and here
We (the sensor modelling discussion group) suggest to rewrite the requirements to allow exceptions - for example
The text was updated successfully, but these errors were encountered: