一种缓存相关的抽象方式

[tiye]

图形界面的开发当中经常提到两种方案, 我从 Gemini 导出两个定义:

• Immediate Mode

  定义： 即时模式是指在每次绘制循环中，直接将所有图形元素渲染到屏幕上。这意味着，在每个帧中，程序都会重新创建并绘制所有图形元素，包括几何形状、材质、纹理等等。

• Retained Mode

  定义： 保留模式是指在程序启动时，将所有图形元素预先创建并存储在内存中，然后在每次绘制循环中，根据需要对这些元素进行更新和渲染。

这里讨论到这个问题, 是因为我注意到 Calcit 中其实频繁遇到也在反复尝试去解决这两个问题.

以往的界面, 比如 DOM 当中, 通过 jQuery 去操作, 或者加上 Backbone, 甚至 MVVM, 都明显在 Retained Mode 这一块.
而 Canvas, 更接近 Immediate Mode, 尽管现实当中比如 pixi.js 或者其他游戏引擎也更多能看到 Retained Mode 样子.
就我了解到, 也只有一些客户端开发界面, 简单的场景, 才会真的从 Immediate Mode 方案去用, 且限制很多.
而 Web 开发, gtk, Qt, SwiftUI, Flutter 等等, 总是大量 Retained Mode 的样子(我自己涉及很浅, 不确切).

React 带来的一些观念确实是非常异类的, 从理论模型上, 就往 Immediate Mode 去靠了,
而且, React 借道 FP 理论, 引入不少的概念, 加强其理论模型, 以及强化高阶函数的使用.
后面 React 发展的情况不说了, 但 Respo 以及 Cumulo 这两个项目是深受早期 React 的思维方式影响的.

我注意到的一点是, 当我们的程序从 C 逐渐结构化的时候, 反复把内存管理局部化, 自动化,
先是从 jump 到 goto, 以及从 goto 到 if/else while/loop 的循环,
同时有 lexical scope, 函数被调用时, 自行管理变量的加载和释放, 只是返回计算结果,
另外面向对象也把属性收拢在对象上, 跟随对象的生命周期进行管理.
更不用说 FP 语言当中, 以及 Rust 当中, 更加细粒度的内存行为的控制了,
这大量的工作, 都让全局状态被拆解, 各自管理, 让程序更加可靠... 至少在业务允许的范围内尽量做到.

但是, Respo Cumulo 这种依赖 memoization 和 data diff 的方案有一点反其道而行之的意思,
当然, React 当时也是这样的, 因为真实的 DOM 在页面上是巨大的状态, 在 React 当中需要模拟,
因而, React 渲染到界面更新的过程当中, 会反复和之前的状态打交道, 用来跳过计算, 用来做 diff.
而这就对我们以往的大量工作造成了干扰, 那么辛苦把状态拆开隔离好, 现在却要引用得到处都是?!

我这两年折腾 Calcit 跟 Rust 各种能力上的对比, 开始深刻体会到这些抽象方式带来了哪些可靠性方面的保障,
特别是 sum type, pattern matching, traits, 这套组合的功能, 带来了很实用可靠的抽象能力,
但是, 实际的互联网产品, 数据库是状态, DOM 是状态, 两者贯穿程序和框架的方方面面, 并不是用上述手段简单就能解决.
我们有什么通用且强大的手段, 对于状态能做统一的抽象, 在性能, 复用, 可维护, 都表现优秀呢?
可能说 React Component 这类的形态确实已经非常强大了, 通过框架和运行时做调度. 但不能算很通用的办法...
(对于 Algebraic Effects 我没有实际使用的经验, 这里无法展开对比)

就是一个思路, 没有想到什么答案. 要说期待的话, 我也希望有类似 Trait System 这样的方案来描述状态.
当我们对于包含状态的逻辑做组合的时候, 也要变得灵活, 且易于扩展和维护.

[tiye]

当然也不是没有把局部的逻辑通过全局的或者外部状态来做维护的, 我指的是 memoization.
可以参考 https://taolun.moonbitlang.com/t/topic/958/1
借助 memoize 函数, 在普通的函数调用当中可以尽量少被感知地插入一个状态.
Respo 用了一个 capacity 为 1 的方案来做 memoization.

但使用的场景有限.