Clikt 真是太牛逼了，艺术啊，一个 ArgParser 做成简直和 Lexer 一样的考虑程度，心细如针啊，真是一个能拿来实现 Proguard argument parser 的大框架。

我原来以为自己对 ArgParser 的执着过度了因为它不过是个打杂的东西，ParserKt 才是正戏，而且说穿了他们俩除了接口漂亮也都没啥实际算法，花皮糠枕头，没想到还真有框架做得比 parsrekt.argp.ArgParser 还要绝…… 密码提示框，解析一对 -map a b 这种参数，我都想不到有 CLI 程序这么现代化啊，这到广义序列化的范畴了吧,,,

已经支持了 multi-param ，我看看接下来怎么操作

支持了我可一点不开心。 我查了一下一些语言实现的 CLI 参数， ruby, python, lua, gcc, clang, rustc, php, squeak, java, javac, kotlinc ，它们没有一个需要所谓的 multi-arg ，顶多要一个 multi item / mssing-prefix interprete ，真是白白浪费自己框架的输出代码体积……

看到这里我就莫名觉得 ArgParser 的设计也真是牛逼，只是给每个 Arg 都加了 convert 函数式属性，就同时做到了另两个框架特殊处理的 validate 和 convert，还有什么 -v -h 这样的 "eager argument"…… 调用 SwitchParser.stop() 和 throw ParseError 不就做到了么？起那么多名词，却背离了框架所应解决问题的本心。抛弃JVM优雅性的过度封装。

其实从action封装的这个角度讲，那两个框架还不如 Python 的 argparse 。人家是只用了一个 ActionContainer ，我的做法和它大致一样(只不过是静态检查的)。
也有一些框架是按 argparse module 的模式照搬的，可惜它们的其他基础部分太烂…… 而且现在的程序员，估计都喜欢搞一些花里胡哨的东西显得自己很懂、很牛逼，却忘记了自己是在解决问题，应该站在问题的角度为它服务，而不是凌驾于问题之上，刻意套用狭隘的语言特性。

真正牛逼的算法大佬从来不屑于在这种破事上费功夫，我们这些做封装的，有什么脸去炫技…… 框架只该考虑优雅地定义、实现好它的本职工作，而不是在后面的算法没啥特色的情况下硬上「高大上」的 API。

就是对自己的能力没有自信才会作这种腔调！如果真的把自己当程序的设计者，就应该有为了程序舍弃自身的觉悟才对。

……写了半天我自己也给绕糊涂了，ArgParse 有三种arg: flag, param, item ，但其 param 分为强类型(1~4) 与弱类型(moreArgs, resucePrefix) 两种，分别存储在 tup 和 dynamicMap 里…… 这次遇到的坑就是 dynamicMap 里存项是 T 但 tup 里就是 OM<T>，不一致啊。 改起来就超级麻烦，必须得重构了，不然不优雅性就要暴露到接口上

这个该死的解构定义是万恶之源，为了它我不知道执行了多少次测试…… 而且每次都百思不得其解，就为了不分情况的返回 pair，提供一个可变的 OM<T>，而不是分情况往 tup 或 dynamicMap 里写值。

因为数据结构动态类型程度过分，赋值的时序关系没注意到就容易踩很多坑…… 看来 Kotlin 的 local function 也一定不能混乱整个函数内部的代码行号和执行顺序
还是强类型语言好…… 每次 unchecked cast 都好怕的 😱

……又是我最讨厌的动态类型

突然觉得自己花这么大力气实现这些东西，就为了和人斗气值不值得…… 与天斗、地斗、人斗…… 何必呢，也伤了自己

我觉得现在 ArgParser 仍然是有特色，但再也不有趣了。 虽然我也修复了三四个bug，但它不像以前一样鲜活灵动了。

我感觉它是黑色的，有一大片功能平常不会用到，我讨厌这种藏在阴影里的代码。

放眼望去仍是密密麻麻的代码，明明已经很努力的在简化了的说…… 可现在看起来，这代码更冗杂了，提不起阅读的兴趣了，即便我统一了泛型数据类型…… 还是不习惯，怎么办

老实说我最开始的方案是利用 NamedMap 的动态类型，在解析可重复参数时建一个 MutableList as Any 再在下次 get as 回来(就是getOrPut)
后来才发现这是个大问题，而且用自己开始弄好的 OneOrMore 封装明明也完全可行的说……（看测试里的用例加了冗余类型参数 就怕麻烦没改 NamedMap 的型参） 不过这种框架也不好写就是了。

回过神来， SwitchParser 用类级抽象的价值开始显现了，成功把巨大的 onPrefix 子程序抽提成 3+2 个依赖前缀名的小子过程

同时还修复了一个 dynamic arg 的 bug 和解决了 command alias 的支持问题。 好了现在只剩下 subcommand 一个没支持了，嘿嘿……

或许重构会迟到，但永远不会缺席。 make argparser great again…… （草）

迫不及待地想把那个高大上的库打得落花流水了，我是指 API 和实现优雅性上。
马上就没有它支持我不支持的功能了，草（不过还是觉得好无聊啊， multi param argument 不知到底有何意义…… 很好用么）
真希望以后发布了会成为那个库对比名单上不敢写的东西啊，毕竟已经多了这么多功能了…… （虽然我还是觉得那些功能纯属鸡肋）

唉，果然还是工程上的事人多些吧。 Kotlin 的解析组合子库，除了 ParserKt 外只用一两个，太无聊了…… 算上 JVM Java Scala 的估计也不多。
现在的 JVM 程序员怎么思想都这么封闭…… parser generator 倒是见过不少