说起来，关于类似 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 好了（笑）

……我不明白
(0, 0) (1, 0) ...(x, 0) 的顺序么
那么 for x for y 呢
那么用 comprehension 呢
那么左开右闭区间 有没有写错 overlap……

是 x, y
w, h
n, m
i, j……
它们有多大的关系……
为什么我觉得不能混用
到底有多少约定俗成，什么含义……

用 user-session-wise state 也是可以的吧，每次判断 state 行事，然后 assign state = nextState(state)

fun onMessage(m: Message) {
if (state.predicate(m.text))
state = state.next
else state = State.INITIAL
}

本来是 《Lua 设计与实现》 这本 #book 的知识点 #PLT

我找不到，看看这个 http://tecdump.blogspot.com/2012/07/coroutine.html

协程是 Melvin Conway 于 1963 年提出的，并发计算流程控制的概念，指两个子过程通过相互协作完成某个任务；好比下棋博弈一样。

“一个非对称协程可以看做是从属于它的调用者的”

还有，对称式协程的特点是没有 suspend/resume，只有 transfer

而且非对称协程可以实现对称协程

对称式和非对称式协程机制的能力并不等价，但事实上很容易根据前者来实现后者。
不少动态语言(Python, Perl, Lua, Ruby)都提供了协程或与之相似的机制。

非对称协程更具结构，而对称协程更灵活一些（好比 for 和 while+break）

https://t.me/kotlin_cn/9101 #Kotlin