毕竟 CBLR 和 SCP-079 都是 Python 实现

我还是不想再总结这次了，没意义，大家心里明白就好。

我是没有话筒的那一个，你们明白这一点就知足了。

刚才一个大概是 SCP 组内的人员解释了一下，SCP 和 OhCNZZ 关系不大

结合之前 @OhCNZZ 删除但被我看过的一条广播（貌似负面评价了 SCP 的 LONG bot）

我觉得这应该是误解了，既然这个频道没人看，名义上道歉一下吧
（嗯。以上。

https://t.me/c/1270345254/70430 #statement #privchat

https://github.com/ParserKt/ParserKt/blob/master/src/commonMain/kotlin/org/parserkt/pat/complex/InfixPattern.kt#L40
这一行注释我改得不对……

https://t.me/c/1270345254/70951 #PLT #parsing #privchat

说起来，关于类似 Telegram bots 这样的东西，我想面向 1:1 关系/流程建模，而不是面向事件 handler/callback 建模

感觉还是不喜欢显式状态机/event handler query 的东西

有人有相关经验吗（哪怕是用闭包什么的）？
coroutine 会对这样的封装有帮助吗，要求支持最大 application scope 的状态

1:1 关系例如 TimerMap<ID: Any> { fun createFor(id: ID, op: Comsumer<ID>) ; fun cancelFor(id: ID) }

感觉面向流程建模和面向 event+state 建模在设计直觉上也差不多的，就是 state 可能维护起来压力略大，不知道如果可以面向 procedure 本身建模，会不会在可维护性有提升

1:1 关系说的就是类似 Telegram bots 这种关于（用户上的状态）的 handler

想想 iseki 能随便 persistent 掉 Kotlin continuation，太dalao了 （

感觉 OOP 的（单向）子类 extends 超类偶尔有点糊……

constructor 的 call-super 里不能用到 this，因为对象创建里每层架构器都要先调用 super 才能运行

有时候 override val 也不得不改成 fun。偶尔超类架构器用个闭包 hack 一下编程风格都提心吊胆，心累……

不过要是先运行子类 constructor 再运行超类就反了，而且「继承」的确是单向关系，不能循环引用……

之前写bot 用的node库叫telegraf，里面有个 scene 的模式，就是面向流程的模式

🤔看起来这个观念挺广泛的

我只是说这个写bot还挺舒服的

特别是有比较复杂流程的bot

其实这个也算是封装了一个基于状态机的 handler

sence greeter
onEnter = say "Hi"
onLeave = say "Bye"
onMessage = if (it.text == "hi") leave()
else it.replyWith("say hi")

我之前臆想的是类似 Kotlin/ES6/Python 的 await/async 的那种，显然单单 await/async 做不到良好处理这种本质是状态机的模式

看来仅仅用函数闭包也是足够的

其实听开发 Kotlin 的朋友说，Telegram 的 Bots API 的 message variants 处理得也相当“动态类型”

弄得别人建模往往就只能判断 hasWtf 再 getWtf，没有子类型

我觉得这样的话干脆直接弄 flag 模式，containsAll 好了（笑）