配置文件中的嵌套字典的数组类型的配置，各位实际生产商使用的多不多？

[tctc4869]

经常要使用配置文件，比如 json，toml，目前只使用了字符串，数字，bool 类型，简单数组（只有数字，字符串，bool 类型值的数组），字典等

那嵌套字典的数组类型的配置各位使用的多不多？ 什么是嵌套字典的数组类型的配置？ 在 json 中，就是 [ { "a":0, "b":"asd", "c":"abcd" }, { "a":0, "b":"asd", "c":"abcd" }, { "a":0," b":"asd", "c":"abcd" } ] 在 toml 中，就是 [ { a=0, b="asd", c="abcd" }, { a=0, b="asd", c="abcd" }, { a=0, b="asd", c="abcd" } ] 这种嵌套字典的数组配置的类型，各位实际使用的多不多？

[kkkkkrua]

不就是数组配置？挺多的啊，yaml 中
XXX:
-
A1:a1
B1:b1
-
A2:a2
B2:b2

[tctc4869]

@kkkkkrua 不是简单的值数组，而是嵌套字典的数组，这个使用的多不多。

[kkkkkrua]

@tctc4869 #2 看你的示例，没看出来怎么嵌套，你那个就是简单的对象数组的 json 格式

[tctc4869]

@kkkkkrua 值数组就是[1,"456456",true,-1]这种，嵌套字典的数组，就是[{a=1},{b=2},{c=2}]

[tctc4869]

@kkkkkrua 对，就是对象数组，在有些地方叫字典数组，toml 里叫表数组，这个实际过程中会经常使用么？

[kkkkkrua]

@tctc4869 #5 孤陋寡闻了，原来 TOML 是那种配置啊，TOML 格式的配置里，没有发现过使用对象数组的，一般都是普通的值对象，不过其他配置格式里挺常见对象数组的

[tctc4869]

@kkkkkrua 我的疑问是，对象数组这种配置，用在配置文件中，实际过程用的多不多，无论是 json，还是 toml 。如果是的话，为什么会在配置文件里用对象数组。

[no1xsyzy]

一个例子是 Windows Terminal 配置（ JSON ）里有 profiles.list 和 keybindings 都是对象数组
Github Workflows 和其他的 CI，以及 Ansible 也有这类，用以表示接连进行的操作。
感觉是可自定义程度非常高的应用才会有。

[no1xsyzy]

想了想，假设所有的配置都拟似到 s-expr 的话
那么 Array of Object 实质上等效于 (begin ... func calls ... )
也就是说，它的等效于无控制结构的一阶谓词逻辑
哦，CI 这一类似乎有 If 的控制结构。

[no1xsyzy]

@no1xsyzy 说得有点难懂……
就是说，array of object 就是写代码（使用一种不直观、也不像是在写代码的 DSL ）了。

[tctc4869]

@no1xsyzy 谢谢，我其实很疑惑对象数组，会有人配置么，数组用的多的应该是值类型的数组，对象数组，我也用过，不过是在 js 里配置过对象数组抽象常用的 if 逻辑去判断

[tctc4869]

@no1xsyzy 比如。

判断一个请求的某个参数，是否合法，比如是不是数字，如果是，有没有超过最小值，如果是，则参数内容是合法的，如果其中一步错了，就代表这个请求的参数内容是非法的，这个应该是对象数组配置的体现。

[no1xsyzy]

@tctc4869 就是说这个配置复杂到写代码才能解决，但配置文件的读取者因为某种考虑（ eval 的安全性？避免自己偷懒用 eval ？）或者是单纯的脑抽，不用正常的代码语言解决，自己设计了一个功能很有限的 DSL 来解决配置文件内嵌入复杂逻辑
而且很可能又要谈一遍格林斯潘第十定律。

[tctc4869]

@no1xsyzy 一般的参数验证不就是这样的么？为了少写重复的验证代码，就封装常用的验证方法，就用类似对象数组的形式配置
比如 java 的请求验证注解

[tctc4869]

@no1xsyzy 难道还有更高级的形式，不需要对象数组也能？

[no1xsyzy]

@tctc4869 注解确实是 DSL，麻烦点在于比较难现场扩展，导致必须事先定义一大堆注解。
传一个 lambda 不方便吗？。

[tctc4869]

@no1xsyzy 还有一个需求，

配置一个请求处理 action 的参数验证，除非对某个参数有特殊验证需求，不然常用参数验证，都不能写 java 代码，甚至所谓的验证注解也不能写，必须通过动态配置字符串搞定。这样的话，是不是只能用对象数组了？

[no1xsyzy]

@tctc4869 你也可以饯行格林斯潘第十定律（开玩笑的

你是发现某个需求你直觉上觉得可以用对象数组解决，但觉得太奇怪了么？然后拍脑袋也没想出什么其他办法
如果只能做成配置，那确实就是对象数组或者格林斯潘第十定律。这个需求本身比较诡异罢了。
不过这个需求本身需要被挑战 —— 安全性的话，如果你做的解析器会执行有风险的内容，也逃不过的。Github 不是都出了环境变量泄漏的问题吗？

[tctc4869]

@no1xsyzy 这是权限安全设计管理的事情，是另一个层面的问题。

[tctc4869]

@no1xsyzy 用纯字符串的配置替代一些必须要基于语言内置的组件才能做的配置，也能实现不重启服务端情况下的动态更新一些简单组件的配置，那注解这种就不行，注解本身是语言内置的

目前觉得比较人性化的配置语言是 toml，之前想过用 json 和 xml，yaml，但是我自己觉得，手写 json 有双引号困扰，xml 嵌套写多了看着乱，yaml 还有缩进问题。

[no1xsyzy]

@tctc4869 Java 不清楚，注解是在 javac 中完成的吗？ *.class 文件反编译的话只会发现被展开的注解吗？
Python “形似注解” 的 decorator 就比较随意了，就算写代码也可以动态加载（解释语言的好处）

不过我指的不是注解更好，而是嵌入一个常规的解释器（比如 Lua ？）更好。
不要半吊子地弄个不完整的 DSL，几乎不存在必须 DSL 才能解决的问题，而且这类问题基本有现成的 DSL
绝大部分代码不可能遇到前无古人的有效需求