#Haha 仁者见仁😂

#Kotlin #learn

Kotlin 的 SAM 实现真的连 this 都不能有啊……

我突然意识到自己写的代码多半都有内存泄漏😢 onChange{} 是舒服，一不小心就忘了内存泄漏。。。

what the fuck，有 GC 也内存泄露你的应用逻辑是多复杂

你只管往舒服的写
不要给自己找麻烦
提高抽象层次对进一步优化有好处

🤔你的意思是 one-shot Listener
你的意思是设置 onChange 不能拿到一个“配置”对象，太死板？

是不是你多想了😳
看起来这是框架的事情

正在用 TornadoFX 他的 onChange 就有这个问题

🤔 被 onChange 的对象…… 就是 Listener 闭包呗。

我是指 A.onChange() 的 A

是啊，onChange 的 listener 嘛
不就是和 Listener 模式的 this 不一样而已

我没有任何办法拿到 Listener 或 能取消掉监听器的句柄，除非我退化成最原始的写法

这是框架该做的事情吧……🤔

你这个内存泄露连带资源泄露不？
e.g. 无效的 android Context 通过闭包泄露

比如呢？
e.g. 一个 File 应该在一个 basic block 里就 close，而不是随函数作用域 close

你的 Listener 引用是放哪里的
你 override 的 onChange 是哪里创建的

🤔之前见过一个 Android 的例子，要求应用全局持有一个 class instance
最后是并行 service 解决了

其实有一个缓解的接口是使用弱引用的，但是emmm Tornado FX没弄对应的 Kotlin 版

🤔🤔🤔
常见 JVM 是不需要弱引用去解决循环引用问题的

弱引用往往就是 缓存