1.6 KiB
1.6 KiB
讨论：
- Future 用 interface 还是闭包：性能应该差不多，如果没有其他方法要暴露，感觉也没有换成 interface 的必要，interface 多一个对象分配。先添加 Then 方法方便未来替换。
- 几个方法提供不同参数个数的版本还是用 tuple：如果编译器不支持可变泛型参数个数和特化，我倾向用 tuple 先简化实现，tuple 的开销应该也容易被编译器优化掉。多个方法让用户选择 Await2/Await3 这种也恶心。
- 是否 Cancellable，暂时不加进去，多一个 context，也不一定能快速稳定下来，可以后面根据实践再改。
- Executor 可能会变化，目前提供的 Run 是阻塞的，也可以把它做成异步。
- 尽量再隐藏一些辅助类型，比如 TupleN，可能之提供 tuple 的构造和返回多值。内部的 libuv 如果隐藏可能要暴露同等接口，先不动了
- 性能可能做个简单测试，但不是关键，只要别太差。未来可能会尽量减少 executor 的切换、尽量多并行
- 异常兼容性：目前没考虑，这个要在回调里处理可能困难，要么就在 await 上处理，可以往后放一下，毕竟 golang 主要是以 error 为主
- 可能先看一下如何在 go+里面集成，判断目前的设计实现是否合理
- 多封装一些库看看通用性和易用性，_demo 里几个简单例子基本符合预期，还需要更多检验
TODO：
[ ] 1. select 兼容 （可能把 Future 改为 interface 更合理？） [x] 2. Future 多个 Await 只会被执行一次 [x] 3. Future 添加 Then 方法，不推荐直接当作函数调用，方便未来切换