Closed GreyElaina closed 1 year ago
动机:我对目前的用法不满意。
应该需要让用户填一个 express,然后 Overload 就直接被操作着填进去。
express
@Fn.complex( TypeOverload(identity="event_type", execute_exp=lambda cx: cx.ref("event")) # Overload 要求 express 求值出来的形式。 # ^^^^^^^^^^^^^^^^^^^^^^^^: Express, 执行这个 lambda 就是求值了。 # __init__((FnOverloadEvalContext) -> Any), 这是 TypeOverload 的对 express 的签名。 ) @m.entity(fn, {"event_type": TypeOverload.build(MessageEvent)}) # collect 时要怎么办呢……
我们应该同时考虑到 execute 与 collect,所以 express 需要有两个版本吗? 签名的构造(Collect),签名的提取(Execute)。 ……只不过这里的提取,看实际情况,更多应该用 “匹配” 更妥当准确一些(Target)。
这套体系,不过是对目前已有体系的补充封装而已,但是必要的。
collect 时应该如何呢……直接 TypeOverload.build(...) 吗?我不知道。 那就这样做吧,由各个 Overload 实现自己定制,但都用 build_xxx 类似的形式。
TypeOverload.build(...)
build_xxx
express 会在 1.3 实装
designed
动机:我对目前的用法不满意。
应该需要让用户填一个
express
,然后 Overload 就直接被操作着填进去。我们应该同时考虑到 execute 与 collect,所以 express 需要有两个版本吗? 签名的构造(Collect),签名的提取(Execute)。 ……只不过这里的提取,看实际情况,更多应该用 “匹配” 更妥当准确一些(Target)。
这套体系,不过是对目前已有体系的补充封装而已,但是必要的。
collect 时应该如何呢……直接
TypeOverload.build(...)
吗?我不知道。 那就这样做吧,由各个 Overload 实现自己定制,但都用build_xxx
类似的形式。