Maybe Not - Rich Hickey
ClojureTVYouTube ↗
延伸阅读 1
字幕解读
Rich Hickey 反对在可复用数据 schema 中预先把字段定为必需或可选，因为 optionality 取决于具体使用上下文。稳定 schema 应描述可扩展的数据形状，调用边界再表达需要哪些信息；过早固定约束会妨碍数据演进与组合。Clojure spec 让规格可检验、生成数据并服务于不同边界，同时保留结构演进空间。
自动字幕 · 引文按字幕原文展示，可点时间戳回看片段。
内容要点
- 字段是否必需取决于某次调用的上下文，不应被固化为所有用途共享的 schema 属性。
- 把数据形状与边界要求分开，可以让 schema 复用并逐步增加信息。
- 规格除验证外还可生成样本，帮助检查约束及兼容性。
视频章节 6
- 从 optional 的含义开始
- 要求与放宽要求
- 使用上下文决定必需性
- 数据形状与 schema 演进
- 边界上的请求规格
- 规格的范围与组合
具体观点与证据 4
放宽输入要求或增强输出保证在语义上应兼容，但把普通值改装Maybe等包装可能让调用者必须改代码。
针对演讲所比较的包装类型接口，不是否认静态类型检查的作用。
an easing of requirements should be a compatible change字段是否必需取决于使用场景，把可选性固定进通用聚合定义会阻碍schema复用。
函数调用边界可以规定要求；批评的是脱离上下文的统一要求。
it's a mistake to put optionality in aggregate definitions是否需要地址与提供地址时需要哪些字段是两个独立约束，应可分别表达。
嵌套schema需要深入到属性树表达条件。
addresses are optional but if you give me an address you have to give me a whole address调用边界的选择器表达最低信息要求，允许额外字段流经不关心它的处理阶段。
开放式spec设计原则，不是要求安全协议接受任意未知输入。
this is just minimal requirements you can always have more stuff补充字幕原文 2
同一字段是否有用或必需，需要结合消费该数据的上下文判断。
information in a certain context so when共享 schema 不应仅因某个局部上下文就收紧所有用途的要求。
schemas just because the contexts are解读边界
这是 Rich Hickey 对数据建模和 Clojure spec 的论证，不是对所有静态类型系统的完整比较；字幕中的部分示例 ASR 有误，且演讲没有量化该方法的工程成本。