但是，这里所认为的 AXML 文件基本结构，我们之前写的复用库里可全都包含在内呦。上面的例子就是经典的 Cond(flag, item), 这里 flag = int32

我最后考虑了一下，好像 Writer 还是必须支持 position 的…… Java 的 ByteArrayOutputStream 在内部就保留有…… 然后就可以有 aligned 这个 pattern

为了 Cond 的 flag 在一些极端情况下的可用性（比如 flag 的 index 是从 1000+ 开始编列的）
必须有一个 map 的 pattern helper，来把输出映射到特定值，再映射回来。

aligned 不应该作为一个 pattern 出现，因为它实在不好取类型，Nothing? 是错误的办法
但可以作为类似 EndianSwitch (PrePost) 的东西出现

特立独行的 pattern

#dev 汲取之前的教训，我再也不为了让测试通过而想当然地改代码了，至少在调试分析以后找出问题根本原因所在，才能算成功。

任何可能出错的地方都会出错……
当时我还检查了很多遍，自以为该 update 某变量的所有地方都检查了，看来好眼睛不如好实例代码、熟练的 IDE 分析工具使用，重点是难以抓住的，肯定要多测试。

结构和解析器，完全可以写在一起。

现在 Int16/Int32 vs. Short/Int 又成问题了，唉，项目里真的没办法完全统一啊

目前和二进制数据模式相关的基本是 Int8 式位长名字，无关的则是 Byte 这样的 kotlin 式名字

如何？EDSL 式的定义方式

想了半天，我觉得要最下面那个就够了。

感觉自己发现了 Kotlin 很 Scala 的一面（喷）

但我毫无办法，用一元正号是有优雅性的，它在 Scala 里是 generic type parameter covariant 的 notation，+int8 给人感觉是『更大层面的 int8』，也就是超集 kotlin.Any 层面的东西。

也可以少做一点 type coercion，只需要把这一个东西分开成两部分就好了……

其实把复用库和应用程序放在一个 subproject 里开发是个错误，真的。至少应该分两个 subproject，然后加依赖……

我没想到我会对复用库部分写那么多……

其实这个建模方式是错误的，不是因为我还没有设计某某结构，而是这种建模方式…… 本身不利于使用，也不是 org.duangsuse.bin 的设计目的。

所以，最关键的事情是先弄明白它的文件结构到底是怎么定义的，硬编码可耻。
死算 offset 的解析器和纯流式序列化器是完全不一样的，我们可以做得好看的多

但是在那之前，我们得先支持 offset 模式，来支持这种广为使用的数据序列化编码方式……

我觉得我得先对可预测的文件结构多写几个测试，这样也不会让项目偏离实际。

我没有很好的解决方案，因为 offset 在读取时需要流支持 mark/reset，这不清真
它在写的时候更麻烦，几乎不可能实现

唯一的办法是单独给它自己写读写器，但其中又貌似有规律可循…… 这一切都是因为我们没有任何办法在 Seq 里访问之前存储到的数据，如果可以的话就能实现一个大致可用的版本

也可以用『传统』（当然是我自己的传统）的 contextual 解析器，用闭包混数据进去，允许单向可读访问。
但我还不知道写的时候该怎么写