Figtree - 节点配置文件

什么是 Figtree？

Figtree 是一种数据格式，主要用于配置，具有节点和部分。它看起来有点像这样

// C-style inline comments and block comments are allowed
myconfig {  // nodes consist of an identifier followed by a brace-block
    // each node can have a number of key-value attributes attached.
    // keys must be strings, but values can be strings,
    // lists, ints, floats or bools
    "key": "value",
    "list": ["one", 2, "three"],
    "trailing comma?": true,

    // nodes can also contain sub-nodes
    empty_subnode {
        /* empty subnode */
    }

    just_subnodes {
        subsubnode {}
    }

    "more": {"key": "value", "pairs": "allowed"}
}

为什么选择 Figtree？

Figtree 非常适合配置文件。配置通常是有限的范围 - 一个 "服务器" 部分可能包含有关服务器配置的详细信息，而 "客户端" 将改变客户端的工作方式，一个 "数据库" 部分提供设置数据库连接的详细信息。在 Figtree 中，这些部分都可以表示为一个节点，而实际的配置则是该范围内的键值对。

Figtree 还试图做到人类可读和可写。语法允许两种类型的注释、尾随逗号以及各种不同字面量的广泛形式。这意味着 Figtree 文件可以轻松由用户阅读和修改，非常适合配置文件。

与其他格式的比较

.ini/.cfg

• Ini 部分基本上可以直接转换为 Figtree 节点。大多数 ini 解析器将允许在部分标题中使用更广泛的字符范围，而 Figtree 具有更严格的格式。Figtree 部分自然嵌套 - 这可以在 ini 配置中复制，通常使用 '.' 路径格式，但必须由解析器定义

• Ini 数据类型通常相对简单 - 通常只是字符串，尽管一些解析器可能在不同的原语之间进行区分。Figtree 允许字符串、整数、浮点数和布尔值，以及这些类型的混合集合。

• 没有通用的 ini 规范。Figtree 有一个规范，这意味着可以为它编写多种语言的解析器，它们将理解相同的文档集。它还可能在可能的情况下使用熟悉的 JSON-like 数据类型，这意味着用户期望工作的功能可能确实会工作。

JSON

• JSON在嵌套对象和嵌套部分之间没有区别。例如，以下代码可以设置设置a.b.c的值为true，也可以设置设置a.b的值为{'c': true}，或者设置a的值为{'b': {'c': true}}。这意味着，如果没有明确的规范，复杂的嵌套JSON配置文件可能很难理解。

  然而，Figtree区分了嵌套部分（使用ident {}格式定义）和嵌套对象（使用{'key': 'value'}格式定义）。这为figtree文档提供了除了应用特定解析器之外的意义。

• JSON规范常被批评过于严格。没有注释，没有尾随逗号。字符串必须用双引号引起来，规范没有为十六进制、八进制或二进制字面量留下空间。事实上，许多JSON用户被鼓励在读取JSON文档之前通过一个JavaScript压缩器来处理，以删除注释并简化文档。

  Figtree保持了JSON的严格性，但为所有这些区域做出了让步——允许两种类型的注释，尾随逗号允许但不是必需的，字符串可以使用单引号或双引号，数字解析器接受多种格式的整数字面量，以确保用户几乎可以以任何他们想的方式编写配置文件。

• JSON官方将所有数字处理为“数值”，就像JavaScript一样。Figtree在内部将浮点数和整数视为不同的类型，尽管在实际开发中，使用JavaScript的Figtree开发者可能将所有数值视为相同，而使用Rust的JSON开发者可能将整数和浮点数分开处理，所以这种区分在实际中可能不存在。

• JSON是JavaScript语言的一个子集，这意味着任何JavaScript解析器都可以读取它。Figtree不是，也不是我所知的任何语言或语法的子集，因此需要专门的解析器来读取。JSON在多种语言中也有许多解析器。我只知道一个Figtree解析器——这个解析器。这是一个已知的错误...

YAML

• YAML被设计为便于人类使用，这使得它成为一个非常好的配置工具。Figtree也是以人为本的设计。然而，YAML解析器通常比Figtree解析器更宽松——在大多数情况下，YAML会将未引用的文本作为字符串读取。这可能会引起问题，因为用户可能会假设未引用的字符串始终有效，然后突然遇到奇怪或令人困惑的错误。在Figtree中，所有字符串都必须引用。我相信没有哪个Figtree数据片段可以改变值，并且这种改变会意外地改变数据类型。

• YAML可以接受任何数据类型作为键。这意味着键应该引用，除非你希望突然有键是true和false，而不是"Yes"或"No"。（这曾经发生在我身上。这令人烦恼。）Figtree键必须始终是字符串。这更多的是为了方便，而不是其他任何东西——当前的解析器是用Rust编写的，Rust具有静态类型，假设所有键都是字符串可以使构建类型安全的结构体更容易。

• 与JSON一样，YAML处理值映射和列表，没有章节的概念。虽然YAML用户可能会使用一种语法编写一个章节，使用另一种语法编写映射，但解析器将以相同的方式处理这两个。

• YAML规范允许实现者任意加载实现语言可访问的任何类或结构（或者实际上调用任何函数）。这已经在大型库和程序中导致了安全错误，包括Ruby on Rails。Figtree不允许通过巧妙的控制序列创建任意语言对象。开发者可以选择基于特定的Figtree结构序列自动创建语言对象，但他们必须选择开启此功能，并定义这些结构以及语言对象。

• YAML有语法上有意义的空白。这没有什么问题。我喜欢用Python进行开发，很有趣。Figtree可能使用大括号，因为我在决定写它的时候正在使用大括号语言。如果你想编写自己的Figtree版本，可以使用语法上有意义的空白，实际上我很想看看那是什么样子。请不要伤害我。

TOML

• 与ini文件类似，TOML有一个章节的概念。然而，在TOML中，这些章节可以直接转换为嵌套对象——任何有效的TOML文档都可以转换为有效的JSON文档，反之亦然。虽然TOML配置文件的用户可能将章节标题和字典字面量的不同含义分配给不同的含义，但对于使用TOML库的开发者来说，这两种语法意味着完全相同的东西。Figtree总是在章节和键值对之间有一个语义上的区别。

• TOML数组不能包含混合类型。Figtree数组可以包含不同类型的混合。实际上，Figtree数组几乎肯定应该是统一类型的，但这留给开发者强制执行。

• TOML有半语法上有意义的空白。规范的一些部分表现得像基于行的格式，尽管多行字符串和数组可能会破坏大多数简单的行到行的解析器。特别是，字典字面量不能包含换行符。Figtree对此疯狂一笑，允许你到处或无处不在地放置空白。

待办事项

• 词法分析
  • 更好的Unicode转义
  • 其他布尔值吗？
  • 更好的处理多行字符串的方法
• 解析
  • 高级位置详细信息 - 显示标记的开始和结束
  • 通过$reference节点进行插值吗？
• API功能
  • 写入文件
  • 用于操作配置结构体的糖函数
  • 集成序列化/反序列化
  • 是否需要拉取解析器API？