3 ms·
This ended up being the preferred pattern we moved into. If, like us, you were passing the object between two applications, the owning API would serialize the
by 101011 2y ago
This ended up being the preferred pattern we moved into.
If, like us, you were passing the object between two applications, the owning API would serialize the enum value as a String value, then we had a client helper method that would parse the string value into an Optional enum value.
If the original service started transferring a new String object between services, it wouldn't break any downstream clients, because the clients would just end up with Optional empty
- janci 2y agoHow that works when you need to distinguish between "no value provided" and "a value that is not in the list" - in some applications they have different semantics.
- 101011 2y agoYou could treat it as an nullable Option<SomeType>. In practice, as it relates to enums, I don't usually see 'no value provided' as a frequently used case - it's more likely that 'no value provided' maps to a more informative 'enum' value