因为数据结构动态类型程度过分，赋值的时序关系没注意到就容易踩很多坑…… 看来 Kotlin 的 local function 也一定不能混乱整个函数内部的代码行号和执行顺序
还是强类型语言好…… 每次 unchecked cast 都好怕的 😱
还是强类型语言好…… 每次 unchecked cast 都好怕的 😱
我觉得现在 ArgParser 仍然是有特色，但再也不有趣了。 虽然我也修复了三四个bug，但它不像以前一样鲜活灵动了。
我感觉它是黑色的，有一大片功能平常不会用到，我讨厌这种藏在阴影里的代码。
我感觉它是黑色的，有一大片功能平常不会用到，我讨厌这种藏在阴影里的代码。
duangsuse::Echo
……写了半天我自己也给绕糊涂了，ArgParse 有三种arg: flag, param, item ，但其 param 分为强类型(1~4) 与弱类型(moreArgs, resucePrefix) 两种，分别存储在 tup 和 dynamicMap 里…… 这次遇到的坑就是 dynamicMap 里存项是 T 但 tup 里就是 OM<T>，不一致啊。 改起来就超级麻烦，必须得重构了，不然不优雅性就要暴露到接口上
老实说我最开始的方案是利用 NamedMap 的动态类型，在解析可重复参数时建一个 MutableList as Any 再在下次 get as 回来(就是getOrPut)
后来才发现这是个大问题，而且用自己开始弄好的 OneOrMore 封装明明也完全可行的说……（看测试里的用例加了冗余类型参数 就怕麻烦没改 NamedMap 的型参） 不过这种框架也不好写就是了。
后来才发现这是个大问题，而且用自己开始弄好的 OneOrMore 封装明明也完全可行的说……（看测试里的用例加了冗余类型参数 就怕麻烦没改 NamedMap 的型参） 不过这种框架也不好写就是了。
duangsuse::Echo
回过神来， SwitchParser 用类级抽象的价值开始显现了，成功把巨大的 onPrefix 子程序抽提成 3+2 个依赖前缀名的小子过程
同时还修复了一个 dynamic arg 的 bug 和解决了 command alias 的支持问题。 好了现在只剩下 subcommand 一个没支持了，嘿嘿……
或许重构会迟到，但永远不会缺席。 make argparser great again…… （草）
或许重构会迟到，但永远不会缺席。 make argparser great again…… （草）
迫不及待地想把那个高大上的库打得落花流水了，我是指 API 和实现优雅性上。
马上就没有它支持我不支持的功能了，草（不过还是觉得好无聊啊， multi param argument 不知到底有何意义…… 很好用么）
真希望以后发布了会成为那个库对比名单上不敢写的东西啊，毕竟已经多了这么多功能了…… （虽然我还是觉得那些功能纯属鸡肋）
马上就没有它支持我不支持的功能了，草（不过还是觉得好无聊啊， multi param argument 不知到底有何意义…… 很好用么）
真希望以后发布了会成为那个库对比名单上不敢写的东西啊，毕竟已经多了这么多功能了…… （虽然我还是觉得那些功能纯属鸡肋）
唉，果然还是工程上的事人多些吧。 Kotlin 的解析组合子库，除了 ParserKt 外只用一两个，太无聊了…… 算上 JVM Java Scala 的估计也不多。
现在的 JVM 程序员怎么思想都这么封闭…… parser generator 倒是见过不少
现在的 JVM 程序员怎么思想都这么封闭…… parser generator 倒是见过不少
https://github.com/taocpp/PEGTL 草，开始我点进去的时候还害怕这个库非常易读，没想到还是传统 C++……
就是
struct sign: one<'+', '-'> {};
struct integer: seq<opt<sign>, digit> {}; 就是
val sign = elementIn('+','-').toDefault('+').convert { it == '-' }
val signDigit = Seq(sign, digit).convert { if (e1) -digit else digit } 啦。GitHub
GitHub - taocpp/PEGTL: Parsing Expression Grammar Template Library
Parsing Expression Grammar Template Library. Contribute to taocpp/PEGTL development by creating an account on GitHub.
为什么这个道理这么简单，但是明明是大佬的人却不懂…… 我以为高等的 C++ 程序员就会明白，命名不是越短越好、定义不是越长越好；可是为什么我看过那么多框架，懂得精炼的人却那么少。
太聪明了…… 聪明反被聪明误么
parser combinator 是老东西，可是为什么作者凭这个就能叫 "The Art of C++" 呢？还是缺少点文档之提纲吧……
不过我真的喜欢 taocpp 的项目，很有水准而且可以说是“完美符合常规”的 C++ 编程之道
太聪明了…… 聪明反被聪明误么
parser combinator 是老东西，可是为什么作者凭这个就能叫 "The Art of C++" 呢？还是缺少点文档之提纲吧……
不过我真的喜欢 taocpp 的项目，很有水准而且可以说是“完美符合常规”的 C++ 编程之道
duangsuse::Echo
为什么这个道理这么简单，但是明明是大佬的人却不懂…… 我以为高等的 C++ 程序员就会明白，命名不是越短越好、定义不是越长越好；可是为什么我看过那么多框架，懂得精炼的人却那么少。 太聪明了…… 聪明反被聪明误么 parser combinator 是老东西，可是为什么作者凭这个就能叫 "The Art of C++" 呢？还是缺少点文档之提纲吧…… 不过我真的喜欢 taocpp 的项目，很有水准而且可以说是“完美符合常规”的 C++ 编程之道
其实都不是，是我太不懂遵守语言标准代码风格约束了……
为了以更明确的语义解决领域的问题，我不惜牺牲标准的风格，只为追求易读性和无歧义，草。
为了以更明确的语义解决领域的问题，我不惜牺牲标准的风格，只为追求易读性和无歧义，草。
duangsuse::Echo
https://github.com/taocpp/PEGTL 草，开始我点进去的时候还害怕这个库非常易读，没想到还是传统 C++…… struct sign: one<'+', '-'> {}; struct integer: seq<opt<sign>, digit> {}; 就是 val sign = elementIn('+','-').toDefault('+').convert { it == '-' } val signDigit = Seq(sign, digit).convert { if…
其实仔细想想，这行凭能力说话，大佬永远是不会差的。
与其把心思放在猜测每个接口程序员乃至用户会如何使用，还不如好好研究下算法和数学思想，我是智商不够用，被迫选择干这种低劣愚蠢的“优化”的。
既然这么简单都没人用，显然是别人已经知道了也抛弃了，库的作者应该是为算法、技巧和自己的名誉服务，怎么可能应该是给使用它的东西服务？ 看来我想得太多
与其把心思放在猜测每个接口程序员乃至用户会如何使用，还不如好好研究下算法和数学思想，我是智商不够用，被迫选择干这种低劣愚蠢的“优化”的。
既然这么简单都没人用，显然是别人已经知道了也抛弃了，库的作者应该是为算法、技巧和自己的名誉服务，怎么可能应该是给使用它的东西服务？ 看来我想得太多
duangsuse::Echo
4.3K 了
草…… 说起来我今天又靠整日坐+熬夜 把 subcommand 写出来了…… 其实实现思路不咋高大上，而且 可能有缺点。
这样即便能比上另外的库，对我而言又有什么意义……
这样即便能比上另外的库，对我而言又有什么意义……