ParserKt 现在的代码简洁性已经蛮够了，用来实现各种解析器/REPL 都不是问题
因为解析器框架本身很具有复用性，现在又有了 LexicalBasics 对其复用性的利用

可惜 Waxeye 是工程系和学术系表示法的杂交，虽然支持的目标语言多而且也算是蛮工整，
那个又 bash 又 Haskell 的语法规则，我真是一些不懂。

同場加映(別群朋友做的工具
https://forum.xda-developers.com/chef-central/android/guide-tool-projekt-scribt-v1-33-t3503018

三种方法，既能让某个“悬浮窗”对象独立于插件的 static root 或至少不泄漏 Context，又能保证所有事件里能引用到这个对象

泄漏和不泄漏，其实就是时间（生命周期）和作用域（可以引用某对象）的问题。
作为一个扩展，泄漏当然会和宿主的使用方法相关。
Android API Platform 对 android.content.Context 的限制也是可以理解为『宿主(系统平台)』对『扩展(应用程序)』的限制的，这个根本的限制就是，Context 不应该是 application-level 的，而是由类似 Activity 的任务启动时由系统提供的。

不说一些很玄学的问题（比如说弄个 static List<Context> 或者在别的线程操作 Context、把 Context 到处传这样）
比如你要 setXXXListener，我们所需要唯一的限制，就是这些 Listener 实例访问到的 Context 必须是 valid 的，这个容易。
不然就无法保证某 Context 存在的时候，它代表的组件也实际“存活”，仅说 Activity，先存某活动"A"的引用，退出稍后再在另一个活动"B"里访问存下的 Context，整个应用的虚拟机可以复用，但是 A 的句柄却失效了，这就是泄漏问题（也不完全算是内存泄漏）。

模型是 线程(只需暴露出类似 Executor 的代码执行资源)、服务(和线程差不多、接口也差不多，但可以直接封送对象协同并发工作)

1. 只要提供 onDestroyPlugin，利用 /*static*/ var ctx: Contex? = null 就可以在插件移除时保证 Context 不再能被访问到，缺点是这种做法对 lint 不可见

2. 利用 GC 细化封装对实例的依赖（所有依赖 context 的操作和 val ctx 封装成一个类，甚至利用 inner class）
插件的实例保留 Context 量，并且提供所有事件和扩展的 handler，只要应用不再需要插件则对应的 Context 也失去了所有引用

3 . 利用“singleton”的 Service 保留一个 context 引用，在插件移除时候终止 Service，可以保证不会泄漏引用的单实例。
实际上是利用插件和插件Service 1:1 的数量关系设计，而对引用本身依然保持在某种 Runnable 的 object instance 里，但那就和主要的 app_process 的 static root 隔离开了

https://pokfulamhku.com/whfy/ #China #Low #recomended #statement

“国家好、民族好，大家，才会更好。”

哈，我又把 不区分大小写 这个封建余孽给加回来了……

ParserKt 已经维护不下去了，我对自己的代码尤其是 typealias 出现了严重的信任危机
现在极其需要项目管理和构件工具的帮忙

gradle 卡 kotliln compiler 下载，一直没法过
Searched in the following repositories:
Gradle Central Plugin Repository

墙也越来越大了

Gradle 终于开始下载了，还是我 pacman -Syu 以后才能下载的，之前都直接卡死在 select() 系统调用上

我去 gradlew -Dhttps.proxyHost=127.0.0.1 -Dhttps.proxyPort=3129 了 Ali 的 proxy
不对,这个不是阿里的

#zhihu #Java https://zhuanlan.zhihu.com/p/26019083 用了 aliyun 镜像

我开发的动力终于又回来了……

热泪盈眶，终于又有了开发的动力。
好思恋 Gradle 这样的 增量编译啊

世道要变了 （《平凡的世界》里某傻子常说的话）

#GitHub #Project
向 Share/Other/kt_misc/pkt_9 道别！
从此走向独立的道路
11 天都过去了
世道要变了

话说 dalao 们为什么执着于 isEmpty 了 可是我个人觉得 str != "" 更直观啊 而且也很直觉

因为那样更规范、更好引用啊
你可以 str.takeIf(String::isNotEmpty)，再试试 str.takeIf { it != "" } 看看。

"" 是一个字符串常量（同时也是字面量）
一般而言好的程序员都会尽可能避免类似的“魔法常量”出现，能明确就明确，这样会对你以后的重构、维护，以及别人的阅读有很大的好处。

再举一个例子，就是 (s == "") 不如 str.isNotEmpty() 更能让一个重视代码质量的人，想起对『这一块』代码的函数抽提和简化方法，主要是明确性不如后者的原因。和 (size -1) 与 lastIndex 是一个道理，但不完全一样。

比较那一点点的“少击键”的蝇头小利，和以后维护 简单干净 的实锤优势，我想好的程序员不会随便为了节省键盘寿命而按照 Java 那一套写代码的。

退一万步讲，Java 里 == 是引用相等性（对于 Kotlin 就是三等号 === 了），所以为了语义明确， (s == "") 必须被写成 s.equals("") 或者 s.length() == 0
开心一点你甚至可以写成 "".equals(s)

两种形式。如果你的项目里同时出现了这两种形式（实现的是一个目标），会给以后的维护造成麻烦，不如都统一了好。