我不止是群员或“对线者”，同时也是回答问题的人

1. 无所谓，反正这种冲突导致的后果顶多是我以后会重视“消息是群管理的，不是我的”这一条了

以后我尽可能把自己重视的东西多转发，到自己的地界去。

2. 怎么样都可以，随你们看
不过我说的是 Telegram 平台上的文档

不多说了

1.我们尊重你写的文字,我们没有对所有群组试图采取相同的配置,所有的配置均可被更改,有配置问题可以联系群管理员2.文档在逐渐完善

现在起码有两个群在评论这个人

大家的观点出奇的一致

这人疯狂对线

介于 Python 和 SCP 开发组基本都是 Pythoneer

为了大家的交流愉快，非必要请不要在中文 Python 组内激烈交流（以至于对线），容易被部分成员（管理）“上纲上线”地对待。
最后我是个很普通的程序员，无意纷争，退了。 #Telegram #statement #China

毕竟 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 的模式，就是面向流程的模式