MARTE11 — NFP_CommonType shall define comparison operators (eg. =, >, <, *, +, -).

NFP_CommonType shall define comparison operators (eg. =, >, <, *, +, -). This currently does not exist, as a consequence two NFP_Duration cannot be compared one another. For instance, the VSL grammar does allow expressions such "(end - start) < (value=10.0, unit=ms)" (where start and stop are TimeObservation

The issue addresses the absence of operations for the datatype
NFP_CommonType (and its children types such as NFP_Duration) capturing
predefined operators applying on these types. One of the consequences of this
absence is that it is not possible to manipulate values of these in datatypes in
VSL infix expressions (such as “"(end - start) < (value=10.0, unit=ms)", which
would imply that operator ‘<’ is available for NFP_Duration).
As suggested by the issue description, one possible solution would be to modify
the existing MARTE libraries, by adding required operations to
NFP_CommonType or its children datatypes. The main drawback of this
approach is that, each time a user identifies a need for an operator which is not
supported by a datatype from the MARTE libraries, the library needs to be
modified, by adding the corresponding operation to the datatype. This solution is
not flexible.
The idea of the resolution described in the section “revised text” is to provide
users with a flexible mechanism for stating that a given predefined operator can
be used on a particular type (in the context of infix VSL expressions). The core
idea behind this resolution is to rely on the new features introduced in the
resolution to issue 15100. The resolution to this issue introduces additional
syntactic rules to VSL for expressing behavior calls (i.e.,
BehaviorCallExpression). As described in the resolution to this issue, defining
behavior signatures following a procedural style (i.e., capturing signatures by
behaviors instead of operations on DataTypes) can help to limit the coupling
between type definitions and behavior signature definitions (since signatures are
no longer captured as operations of data types). Relying on Behaviors instead of Operations for capturing new operators (e.g., adding predefined operators for
NFP_CommonType) would therefore avoid modifications of existing libraries.
In order to capture the fact that a given behavior actually represents an operator,
a new stereotype, « Operator », is introduced in this resolution. Some text is also
provided regarding how this information can be automatically exploited by a VSL
parser, regarding type inference and scoping.