4 ms·
Requirements change, things evolve. Having bounds in the type system is too restrictive. Even history of "required", rather simple restriction on the value, is
by galkk 2y ago
Requirements change, things evolve. Having bounds in the type system is too restrictive.
Even history of "required", rather simple restriction on the value, is showing that putting that logic into type system is too much of a burden.
https://capnproto.org/faq.html#how-do-i-make-a-field-required-like-in-protocol-buffers https://capnproto.org/faq.html#how-do-i-make-a-field-require...
- skybrian 2y agoThis is true when you can’t upgrade all the data and all the data generators. But there are smaller systems where you can actually upgrade everything you have and set some new requirements for everything coming in.
- yencabulator 2y agoThe other alternative is what protobuf did to solve the same pain: In proto3, all optionals have a default value. They're effectively required where the default value doesn't need to be encoded in the message. The exact different between the two approaches is subtle. Technically you can fancier things with the framework exposing the optional values as set/not set, but in practice a lot of code is a lot simpler with default values. https://protobuf.dev/programming-guides/proto3/#default https://protobuf.dev/programming-guides/proto3/#default
- stouset 2y agoIf the requirements change, you can update the definition in the type system once. And then you immediately know the locations where this new bound is violated.