是解决生命周期不一致的问题

所以你倒是说说 target 和 listener 都是啥生命周期啊？

不是框架 finialize 解决了么
内存管理问题不是 你业务逻辑的资源回收问题
那是相当基础的对象引用图
怎么可能总出问题

他可能是为了 流 式的调用， onChange 返回的是 this；如果用 addListener() SAM 因为kotlin的 lambda SAM 不能拿到自己的 this ，也就没法 removeListener(Listener)

是啊，为了链式调用你就不能用本该返回的配置对象了

所以说是框架的问题，或者是你对框架理解的问题，不是自动内存管理的问题啊

你把 调用线 给梳理一下吧

e.g. 读写一个文件
File.init > File.read > transform > File.write > File.close

前因后果，线性处理结构。

我最好奇的是框架为什么要让用户手动管理 target 和其上的 listener，如果它们是 1:N 的所有权关系

你真的确定会有这种泄露吗？

有现成的binding（内部用finalize解决）

比如说你要一个按钮，点击后自动取消监听？

然后就出现了框架本身不好解决的问题，他们用Java写无所谓，Kotlin写就不太好看了（不够Kotlin

onEach { this@onEach } 也不行🤔
它的 this 难道不是某个 Listener subclass?

似乎不能这么整emmm

那就是扩展的“按钮取消listen”情况了……
非得用 removeListener 取消吗…… 真的必须要这么设计吗

能不能把闭包的逻辑写死点，然后用 Deque 什么的取代对许多闭包的使用？

你不 Ctrl+Q / Ctrl+Shift+P 一下那个 addListener 🤔

哦，我倒是忘了，人家 onClick 流式调用不返回句柄就算了，他这 void ...

真的只适合传统内部类写法，lambda 8行了（除非不需要取消

那怎么办？
val on1 = ChangeListener {} ?

除非你把它包一层，变成 Kotlin。

你用 functional inline 就不用担心 ChangeListener {} 里面还得包一个对闭包对象的调用了，反正是 Kotlin。

#Haha #life #China