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