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

Constants #44

Open
gregsdennis opened this issue Jun 7, 2023 · 0 comments
Open

Constants #44

gregsdennis opened this issue Jun 7, 2023 · 0 comments

Comments

@gregsdennis
Copy link
Member

I initially questioned the need to communicate constants.

If a constant is defined in a programming language, it's intended not to change, and it's likely hardcoded. This means that there's usually no real reason to serialize that value unless some other system needs to know what that value is, in which case it's not a constant in the other system; it's just another variable. It's just data.

However from a codegen point of view, if you're designing the interface that's intended to generate code for multiple systems, maybe you want to define some constants in an common/agnostic format so that the values will be set properly in each target system.

So while constants as a language construct don't generally apply to data transmission (run-time), they can be useful at dev-time to align multiple systems.

To generate a constant, an implementation will need

  • a name for the constant
  • a type for the data
  • an initialization value

The name and value can be accomplished with the current keyword set in JSON Schema, but I think the type needs a new keyword.

{
  "title": "myConst",
  "dataType": {"$ref": "#/$defs/myDataType"},
  "default": "some value",
}

The type defined by dataType will need to be generated at some point.

In a validation context, dataType will simply be a single-schema applicator, much like additionalProperties or then.

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

No branches or pull requests

1 participant