Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unify Argument and Member model-types #96

Open
gunnar-mb opened this issue Dec 14, 2023 · 0 comments
Open

Unify Argument and Member model-types #96

gunnar-mb opened this issue Dec 14, 2023 · 0 comments

Comments

@gunnar-mb
Copy link
Collaborator

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:

  1. 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
  2. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant