Values and types
What kinds of value a Jadpo program works with, how you give a value a meaning in your business, and when one type can stand in for another.
The idea behind all of it: how a value is stored is not what it means. An email address and a username are both text underneath, and an order ID and a customer ID are both UUIDs, but Jadpo treats them as different types. A value becomes a type only by being checked against that type's rules, and the compiler never converts between types without being asked.
| Built-in types Jadpo comes with its types built in. |
| Named types Most of a program's types are named types: a built-in representation, a name that says what the value means, and the rules a valid value must follow. |
| Creating values Applying a type to a value, |
| Validating in the middle of a program To check a value partway through a program, construct it. |
| One form for every type Every type is declared the same way, |
| Signatures use named types A function, action or query can't take or return a built-in representation type directly. |
| Objects An object is a fixed set of named fields. |
| Building a type from other types Most object types are slices of an entity or of another object, so you build them from it rather than repeat its fields. |
| Values that may be missing There is no |
| Enums An enum is a closed list of named alternatives. |
| Collections
|
| When one type can stand in for another A value can be used where its own type is expected, and where a type it widens to is expected. |
| Values never change Every value is immutable. |
| Dates and times The types for dates, times and durations, how to read the clock, and how to work across zones and show a time to people. |
| Standard types Every standard type from A to Z, and what all of them can do. |
What is built says which of this works today.
Markdown for agents: /docs/values-and-types.md.Built from Jadpo main at aee2e8f.