The Interface Exchange Framework. Tools for processing interface/API descriptions in different formats, including the IFEX core format. Some example files are at: https://github.com/COVESA/vehicle_service_catalog.
Mozilla Public License 2.0
14
stars
17
forks
source link
Support for (physical) unit as part of datatype? #113
Consider if it would make sense to add unit to datatype definitions
Traditionally, programming languages do not natively support units as part of datatype definitions, but some special programming environments might. (If you know of any, please provide links, since this may give useful design input).
Of course it doesn't prevent anyone from programming them into their 'system' using generic programming features, such as some meta-data, a string, or adding an enumeration type that lists the units, or whatever!
Design considerations
Layers are always an option, but this might be so generically useful that it ought to be part of the core language.
If units are added as an (optional) feature in the core IDL, there are still considerations:
Physical units such as SI / metric or other systems, usually only define them (or they only make sense) for single (scalar) values, right.
Therefore, defining a unit on a "Struct" makes no sense (or does it?)
Presumably, it would be limited to any scalar type values.
How should it be limited ?
Proposal 1: A datatype with a specified unit must be defined as a separate `Typedef
It would have to be enforced only by tooling implementation, that it can apply only to typedefs that apply scalar types that are only the number types, which are a subset of the primitive types (string is excluded), which in turn are a subset of the built-in types.
Proposal 2: Unit can be specified in any place where a type is specified
The same restrictions on this type being a primitive number-type would still apply.
First reaction:
In my view, number 2: feels iffy. It's somewhat more convenient, but the more "optional" fields are added to each type of definition the weaker the core IDL specification feels. It sort of gets watered down to many possible options, which doesn't feel quite right.
Consider if it would make sense to add unit to datatype definitions
Traditionally, programming languages do not natively support units as part of datatype definitions, but some special programming environments might. (If you know of any, please provide links, since this may give useful design input).
Of course it doesn't prevent anyone from programming them into their 'system' using generic programming features, such as some meta-data, a string, or adding an enumeration type that lists the units, or whatever!
Design considerations
Layers are always an option, but this might be so generically useful that it ought to be part of the core language. If units are added as an (optional) feature in the core IDL, there are still considerations:
Proposal 1: A datatype with a specified unit must be defined as a separate `Typedef
It would have to be enforced only by tooling implementation, that it can apply only to typedefs that apply scalar types that are only the number types, which are a subset of the primitive types (string is excluded), which in turn are a subset of the built-in types.
Proposal 2: Unit can be specified in any place where a type is specified
The same restrictions on this type being a primitive number-type would still apply.
First reaction:
In my view, number 2: feels iffy. It's somewhat more convenient, but the more "optional" fields are added to each type of definition the weaker the core IDL specification feels. It sort of gets watered down to many possible options, which doesn't feel quite right.