其实把复用库和应用程序放在一个 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 强迫症患者还真是有点困难呢！

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

好了，看起来能用的样子。

唯一不满意的地方就是还需要保存 Pair…… 但这其实是必须的，Offset 也是一样
我们的策略是完全解析，也就是说没有无法恢复的字节。

可以试着解析一些良好定义的结构，比如 Java classfile 文件结构，我这里有比较规范的参考书可用。

可以不必严格在 Kotlin Common 里编写主要测试定义，但不得不在 jvmMain 里添加具体实例着实有点麻烦
测试是自动化的，不好拿位图读取这样的任务做…… 也不是不可以

可是 Java class file 需要无符号数值 u1, u2, u4, u8，而现在最大只支持到 u2
不得不多写几个 unsigned extension

u8 已经逾越了 kotlin.Long 能存储的范围，根本无法在不使用 unsigned types 的情况下支持，暂时别名到 int64 好了

模拟了一下 LiterateKt CLI 项目生成工具的工作流程，懂了，但是我在想一个内部的临时印象式程序部分 App(intrinsic, destination, listOf(source)) 时 对那个 intrinsic 莫名头疼，想了很有几遍，现在还不好。