# 规范元数据支持
问题：目前无法为规范附加元数据
能够添加文档字符串（主要用例）会很方便，
或者可能对在特定上下文中使用该规范的信息（例如静态代码分析器、
自定义转换/转换、如何与特定的数据库模式相关联、可读性错误消息
模板、特定于域的关注点，甚至稍后是clj.spec本身）等信息也很
有用。
理论上，现在可以创建自己的元数据注册表并在库级别处理此问题，
一些与规范相关的项目已经是这样做的，但是有一个统一/标准的方法来
做这件事会更好。默认情况下，添加对文档字符串的支持是有意
义的。它可以采取以下额外参数的形式：至少有以下两个
形式
(s/def ::foo "Something that's a foo" any?)
(s/def ::foo string? {:doc "Something that's a foo" :cassandra-type :varchar})
;; 可能的根据实现方式
(s/spec #() :gen ... :meta ...)
(with-meta (s/spec ...))
有几种方法可以实现，各有优缺点
* 实现 IMeta 协议
这似乎是一个干净的解决方案，元数据可以在任何 Spec
级别得到支持（例如非注册的 spec 指针、Set spec 等）。
实现将需要对当前代码进行相当大的更改。主要是向各种
*-spec-impl 宏和糖添加 meta 参数，在 `s/def` 及其衍生
版本的水平。
该方法的棘手之处在于，注册的 spec，那些引用另一个
spec 的只是“链接”（关键字），所以我们现在没有地方添加
元数据。
它们可以实现，返回原始 spec 的“指针”，并在自己的级别上
持有元数据。
*, 简单的注册表（类似于规范注册表，或以某种方式集成到主
规范注册表中）
基本上是一个规范-kw -> 元数据的映射。如果在一个独立的
注册表中，或者以某种方式集成到主注册表中。
这是简单的方法，只支持注册的 spec，元数据与其余部分分
离，会使 spec 实例变得更轻。引用其他 spec 的 spec 将有自己的元
数据。
如前所述，这可以在单独的注册表中完成，也可以添加到主规范注册
表中的 spec 值。
似乎 IMeta 是更好的解决方案，我们可以利用现有的“meta”
