但 Vert.x 用 Router() 更方便，更体贴编程语言

感觉这张路由表非常巨大（

终归还是得写在一个verticle里的

『路由表』(path bindings) 是没有办法的，不是他们起个 endpoint 的名字暴露给你们，后面就不需要有 dispatch 的操作了

这可不一定，暴露到编程语言的『值』里面，可组合性完全可能超乎你想像
路由表和 handler 甚至都可以动态从外部加载，靠 Annotation 这种极其特化的东西是办不到的
反射靠 Annotation 的『语法糖』，可是另一个世界了

httpserver被verticle外部访问是可以的吗？

可是 Router 是一个值啊
HttpServer.setRouter
Router.route

框架的 Vertice 抽象，对面向对象有啥限制是他们的事情，Router 是一个有状态的数据，怎么解耦合是另一回事

也行。。。全局持有一个router？

可以用全局函数设置 Router 实例

而且你也完全可以用良好设计的 Router 模型和反射，支持 SpringBoot 式的 Annotation 配置，理论上这没问题

这是做好了一个更大的情况，不是在保持大情况依然就那样的情况做小的 workaround

而且那么写就要上类扫描啥的

可是 SpringBoot 背着你也要初始化收集它的元数据

谁都逃不掉的，关键是如何复用

就是针对大情况优化，不制造历史问题。

与人方便自己方便，不至于基本模型看不出来，新人上手都困难重重
本来就是个 100 块的价，非得整成 5w 买不下来
本来是玉米粥，非得挂个“黄金粥”，这种傲慢与偏见，才是最大的强迫症。

Parser.kt:155:9: error: inner class of generic class extending 'Throwable' is prohibited
emm...

现在 ParserKt 的风格比较类似『在规范化的同时保证可扩展性』
比较混乱，比如 ErrorListener 就不是一个很好的设计，引起了 error 和 ParseError 的 混淆？

Parser.kt:159:17: error: subclass of 'Throwable' may not have type parameters

#KotlinEmmm 🌚

#Kotlin #code

我真的服了我自己了，我居然把 Tuple 和 Fold 做成了 Kotlin 语言扩展级别的东西了……

emptyTuple<Int>() == emptyTuple<Int>()
tupleOf(1,2) != tupleOf(1)

"abc".asIterable().fold(asString()) == "abc"
"abc".asIterable().fold(asList()) == listOf('a', 'b', 'c')
listOf(1,2,3).fold(JoinFold(0, Int::plus)) == 6

其实我不就想写个组合解析器框架么……