Skip to content

Commit 17ef1fc

Browse files
author
Luke Sneeringer
authored
feat: AIP-141 – Quantities (#7)
1 parent 3d1661e commit 17ef1fc

2 files changed

Lines changed: 86 additions & 0 deletions

File tree

aip/general/0141/aip.md

Lines changed: 79 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,79 @@
1+
# Quantities
2+
3+
Many services need to represent a discrete quantity of items (number of bytes,
4+
number of miles, number of nodes, etc.).
5+
6+
## Guidance
7+
8+
Quantities with a clear unit of measurement (such as bytes, miles, and so on)
9+
**must** include the unit of measurement as the suffix. When appropriate and
10+
unambiguous, units **should** use generally accepted abbreviations (for
11+
example, `distance_km` rather than `distance_kilometers`).
12+
13+
```typescript
14+
// A representation of a non-stop air route.
15+
interface Route {
16+
// The airport where the route begins.
17+
origin: string;
18+
19+
// The destination airport.
20+
destination: string;
21+
22+
// The distance between the origin and destination airports.
23+
// This value is also used to determine the credited frequent flyer miles.
24+
distance_miles: number;
25+
}
26+
```
27+
28+
If the quantity is a number of items (for example, the number of nodes in a
29+
cluster), then the field **should** use the suffix `_count` (**not** the prefix
30+
`num_`):
31+
32+
```typescript
33+
// A cluster of individual nodes.
34+
interface Cluster {
35+
// The number of nodes in the cluster.
36+
node_count: number;
37+
}
38+
```
39+
40+
**Note:** Fields **must not** use unsigned integer types, because many
41+
programming languages and systems do not support them well.
42+
43+
### Specialized messages
44+
45+
It is sometimes useful to create a message that represents a particular
46+
quantity. This is particularly valuable in two situations.
47+
48+
- Grouping two or more individual quantities together.
49+
- Representing a common concept where the unit of measurement may itself vary.
50+
51+
Consider the example of money, which could need to do both of these:
52+
53+
```typescript
54+
// A representation of an amount of money, in an arbitrary currency.
55+
interface Money {
56+
// The 3-letter currency code defined in ISO 4217.
57+
currency_code: string;
58+
59+
// The whole units of the amount.
60+
// For example if `currency_code` is "USD", then 1 unit is one US dollar.
61+
units: bigint;
62+
63+
// Number of nano (10^-9) units of the amount.
64+
// The value must be between -999,999,999 and +999,999,999 inclusive.
65+
// If `units` is positive, `nanos` must be positive or zero.
66+
// If `units` is zero, `nanos` can be positive, zero, or negative.
67+
// If `units` is negative, `nanos` must be negative or zero.
68+
// For example $-1.75 is represented as `units`=-1 and `nanos`=-750,000,000.
69+
nanos: number;
70+
}
71+
```
72+
73+
APIs **may** create structs to represent quantities when appropriate. When
74+
using these structs as fields, APIs **should** use the name of the struct as
75+
the suffix for the field name if it makes intuitive sense to do so.
76+
77+
## Changelog
78+
79+
- **2019-09-13**: Added the prohibition on unsigned types.

aip/general/0141/aip.yaml

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,7 @@
1+
---
2+
id: 141
3+
state: approved
4+
created: 2019-07-18
5+
placement:
6+
category: fields
7+
order: 20

0 commit comments

Comments
 (0)