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
Currently the Core IDL / interface model has one Argument type and one Member type.
Argument is for Method arguments, Members are the items that make up a Struct.
The only difference in the definition is that Arguments can apply a Range (which would augment or overrides the range specified by the item's datatype, if the datatype specifies a range).
The rationale for range in method Argument is, by the way:
It is appropriate that a particular use of a datatype in a particular context (method) can apply its own unique constraints on the given argument
It is convenient to not have to define a new unique type to achieve this.
We could use the same rational for Structs and claim that the usage of a "more primitive" type as a member inside a struct, might want to apply its own constraints.
If we redefine the model to state that struct members are of type Argument instead of type Member, then the types are unified into one:
Pros:
Further unification of concepts. Simplification of model and could facilitate code reuse/consolidation.
Cons:
It potentially increases complexity of implementation for Structs to be forced to handle Range
It should basically be a backward compatible change too, because the YAML syntax does not change (the names of the parts in an Argument and Member are the same), and we are only adding a new potential item to the struct member, which is also optional.
Footnote:
"Range" concept is due for rework in a future spec release anyway. More generally, it is about "Type constraints" that could be more than just specifying a range.
The text was updated successfully, but these errors were encountered:
Currently the Core IDL / interface model has one Argument type and one Member type.
Argument is for Method arguments, Members are the items that make up a Struct.
The only difference in the definition is that Arguments can apply a Range (which would augment or overrides the range specified by the item's datatype, if the datatype specifies a range).
The rationale for range in method Argument is, by the way:
We could use the same rational for Structs and claim that the usage of a "more primitive" type as a member inside a struct, might want to apply its own constraints.
If we redefine the model to state that struct members are of type Argument instead of type Member, then the types are unified into one:
Pros:
Cons:
It should basically be a backward compatible change too, because the YAML syntax does not change (the names of the parts in an Argument and Member are the same), and we are only adding a new potential item to the struct member, which is also optional.
Footnote:
"Range" concept is due for rework in a future spec release anyway. More generally, it is about "Type constraints" that could be more than just specifying a range.
The text was updated successfully, but these errors were encountered: