4 ms·

> Just document that the enumeration is open-ended, and programs should treat any unrecognized values as if they were “Other”. Possibly just showing my lack of

> Just document that the enumeration is open-ended, and programs should treat any unrecognized values as if they were “Other”. Possibly just showing my lack of knowledge here but are open-ended enumerations a common thing? I always thought the whole point of an enum is that it is closed-ended?

sd9 2y ago
I’ve worked on systems which where the set of enum values was fixed at any particular point in time, but could change over time as business requirements changed. For instance, we had an enum that represented a sport that we supported. Initially we supported some sports (say FOOTBALL and ICE_HOCKEY), and over time we added support for other sports, so the enum had to be expanded. Unfortunately this always required the entire estate to be redeployed. Thankfully this didn’t happen often. At great expense, we eventually converted this and other enums to “open-ended” enums (essentially Strings with a bit more structure around them, so that you could operate on them as if they were “real” enums). This made upgrades significantly easier. Now, whether those things should have been enums in the first place is open for debate. But that decision had been made long before I joined the team. Another example is gender. Initially an enum might represent MALE, FEMALE, UNKNOWN. But over time you might decide you have need for other values: PREFER_NOT_TO_SAY, OTHER, etc.
XorNot 2y ago
The first time you have to add a new schema value, you'll realise you needed "unknown" or similar - because during an upgrade your old systems need a way to deal with new values (or during a rollback you need to handle new entries in the database).
- sitkack 2y ago
  Your comment is the only in the entire discussion that mentions "schema". Having an "other" in a schema is a way to ensure you can run n and n+1 versions at the same time. It is Data Model design, of which API design a subset. You can only ever avoid having an other if 1) your schema is fixed and 2) if it is total over the universe of values.
deleted 2y ago
[deleted]
hansvm 2y ago
It's common when mixing many executables over time. I prefer to interpret those as an optional/nullable _closed_ enum (or, situationally, a parse error) if I have to switch on them and let ordinary language conventions guide my code rather than having to understand some sort of pseudo-null without language support. In something like A/B tests it's not uncommon to have something that's effectively runtime reflection on enum fields too. Your code has one or more enums of experiments you support. The UI for scaling up and down is aware of all of those. Those two executables have to be kept in sync somehow. A common solution is for the UI to treat everything as strings with weights attached and for the parsers/serializers in your application code to handle that via some scheme or another (usually handling it poorly when people scale up experiments that no longer exist in your code). The UI though is definitely open-ended as it interprets that enum data, and the only question is how it's represented internally.
int_19h 2y ago
Both are valid depending on what you're modelling. As far as programming languages go, all enums are explicitly open-ended in C, C++, and C#, at least, because casting an integer (of the underlying type) to enum is a valid operation.
- jay_kyburz 2y ago
  My pet hate is when folks start doing math on enums or assuming ranges of values within an enum have meaning.
  - DonHopkins 2y ago
    Like pesky Hex<=>Decimal conversion with the gap between the numbers and the letters, and upper/lower case letters too.
- eru 2y ago
  Yeah, C, C++ (and C#) aren't very good at modelling data structures.
tbrownaw 2y ago
Does a foreign key count as an enum type?
fweimer 2y ago
Enumerations are open-ended in C and C++. They are just integer types with some extra support for defining constants (although later C++ versions give more control over the available operations).
gauge_field 2y ago
Sometimes, one case where I made use of this is enumeration of uarch for different hardware to read from the host machine. The update for for new uarch type is closed ended until there is new cpu with new uarch, which is long time. So, for a very long time it is open-ended with very low velocity in change. It is ideal for enums (for a very long time), but you still need to support the change in list of enum variants to not break semver.
furyofantares 2y ago
This is not really the case mentioned (not API design), but I somewhat often have an enum that is likely to be added to, but rarely (lots of code will have been written in the meantime) and I would like to update all the sites using it, or at least review them. Typically it looks something like this: enum WidgetFlavor { Vanilla, Chocolate, Strawberry, NumWidgetFlavors }; And then wherever I have switch(widgetFlavor), include static_assert(NumWidgetFlavors==4). A bit jealous of rust's exhaustive enums/matches.

sd9 2y ago

I’ve worked on systems which where the set of enum values was fixed at any particular point in time, but could change over time as business requirements changed. For instance, we had an enum that represented a sport that we supported. Initially we supported some sports (say FOOTBALL and ICE_HOCKEY), and over time we added support for other sports, so the enum had to be expanded. Unfortunately this always required the entire estate to be redeployed. Thankfully this didn’t happen often. At great expense, we eventually converted this and other enums to “open-ended” enums (essentially Strings with a bit more structure around them, so that you could operate on them as if they were “real” enums). This made upgrades significantly easier. Now, whether those things should have been enums in the first place is open for debate. But that decision had been made long before I joined the team. Another example is gender. Initially an enum might represent MALE, FEMALE, UNKNOWN. But over time you might decide you have need for other values: PREFER_NOT_TO_SAY, OTHER, etc.

XorNot 2y ago

The first time you have to add a new schema value, you'll realise you needed "unknown" or similar - because during an upgrade your old systems need a way to deal with new values (or during a rollback you need to handle new entries in the database).

sitkack 2y ago
Your comment is the only in the entire discussion that mentions "schema". Having an "other" in a schema is a way to ensure you can run n and n+1 versions at the same time. It is Data Model design, of which API design a subset. You can only ever avoid having an other if 1) your schema is fixed and 2) if it is total over the universe of values.

deleted 2y ago

[deleted]

hansvm 2y ago

It's common when mixing many executables over time. I prefer to interpret those as an optional/nullable _closed_ enum (or, situationally, a parse error) if I have to switch on them and let ordinary language conventions guide my code rather than having to understand some sort of pseudo-null without language support. In something like A/B tests it's not uncommon to have something that's effectively runtime reflection on enum fields too. Your code has one or more enums of experiments you support. The UI for scaling up and down is aware of all of those. Those two executables have to be kept in sync somehow. A common solution is for the UI to treat everything as strings with weights attached and for the parsers/serializers in your application code to handle that via some scheme or another (usually handling it poorly when people scale up experiments that no longer exist in your code). The UI though is definitely open-ended as it interprets that enum data, and the only question is how it's represented internally.

int_19h 2y ago

Both are valid depending on what you're modelling. As far as programming languages go, all enums are explicitly open-ended in C, C++, and C#, at least, because casting an integer (of the underlying type) to enum is a valid operation.

jay_kyburz 2y ago
My pet hate is when folks start doing math on enums or assuming ranges of values within an enum have meaning.
- DonHopkins 2y ago
  Like pesky Hex<=>Decimal conversion with the gap between the numbers and the letters, and upper/lower case letters too.
eru 2y ago
Yeah, C, C++ (and C#) aren't very good at modelling data structures.

tbrownaw 2y ago

Does a foreign key count as an enum type?

fweimer 2y ago

Enumerations are open-ended in C and C++. They are just integer types with some extra support for defining constants (although later C++ versions give more control over the available operations).

gauge_field 2y ago

Sometimes, one case where I made use of this is enumeration of uarch for different hardware to read from the host machine. The update for for new uarch type is closed ended until there is new cpu with new uarch, which is long time. So, for a very long time it is open-ended with very low velocity in change. It is ideal for enums (for a very long time), but you still need to support the change in list of enum variants to not break semver.

furyofantares 2y ago

This is not really the case mentioned (not API design), but I somewhat often have an enum that is likely to be added to, but rarely (lots of code will have been written in the meantime) and I would like to update all the sites using it, or at least review them. Typically it looks something like this: enum WidgetFlavor { Vanilla, Chocolate, Strawberry, NumWidgetFlavors }; And then wherever I have switch(widgetFlavor), include static_assert(NumWidgetFlavors==4). A bit jealous of rust's exhaustive enums/matches.