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

现在 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 解析器，用闭包混数据进去，允许单向可读访问。
但我还不知道写的时候该怎么写

让 int32.array(0, constant(2)) contextual { Seq(int32, int32, offset(it[0], strings), offset(it[1]-it[0], styles)) } 就可以了

我们利用 contextual 在不同的 Pattern 实例里打了个洞，允许传递这样的信息，offset 就可以利用这个信息保存跳过的所有字节，以及在写的时候还原这些跳过的字节

宠物店里新进了一些宠物~ new patterns introduced

int64 magic 0xCAFEBABEL
int32.array(0, 2.statically()) contextual { Seq(::WTF, int32, int32, offset(it[0], strings), offset(it[1]-it[0], styles)) }

（调侃）对严格的中文和 Chinglish 强迫症患者还真是有点困难呢！

面向对象就有一个好，就是数据和行为可以很方便地写在一起，结构化只能分开写、函数式也只能分开写，虽然偶尔这显得强耦合但面向对象的基本模型是完全兼容函数式闭包的。