duangsues.is_a? SaltedFish

duangsuse: 编译lua.c 和luaj试试，mvn启动都够make完的了你觉得jvm搞得起那么重算法的项目吗一个编译型python 恭喜你发现了Vert.x的API 这没什么稀奇，JS玩烂了的东西，移植下没什么局限性啊，不就是按类型和函数名生成方法体？就是说，把处理 @GET("xx") fun f(@Query yy:Int) 的冗余代码写成 route.get("xx") { req["yy"].Int } 的形式而已不要脱离具体用途谈AOP。你是要监听器、替换函…

duangsuse:
既然我们非常清楚DI就是服务于 @addLog class MySvc_() {} 这样在pyjs里稀松平常的「函数字典处理」需求
就像 kwarg fn 和 listener list / get("wtf/"){注册}

我觉得过度设计是要看API易用性的收益的

模板除了 Stream.$OfInt 的自动优化外，还有什么能力吗？

哦，至少可以实现 keyOf(Pair)=[基于反射自动constexpr展开] 的元编程

C++模板属实是唐到家了，我支持过程宏，和反射API保持一致

除了Function/Tuple<T,R> 还有别的应用么……

我不是很喜欢把 compile time 和反射分那么开。 Zig 就完全没有区分，type和generic是const/fun而已

AOP被FP取代的问题，本来就是为了 make compiler happy 造成了冗余代码被接口这些东西耦合，所以要Proxy依赖注入/反射来包一层
结果你又搞个编译期API，还是和Pyjs那样都运行期好了。

这些都是codegen的东西吧，模式明确一个py脚本很快给你生成了

而且，即便函数式er 也很少人用部分传参

f=(A,B)=>A
f1=A=>B=>A

g=(f,A)=>(B)=>f(A,B)

这样的模式，比如f替换 ,为=>
g基本也是一样，加个泛型参数就能生成了

special cases ain't special enough to break simplicity
duangsuse:
Rust的宏就类似template<>匹配，那其实就是语法不稳定造成反射API难产而已

要我说，所有编程语言的语意都是类似的，比如tuple/named/cased 这些数据结构，都可以有相同的方法来复用和利用 (abc)=>type, {kvar: type} 这些无法执行的声明片段
模板只是目标最单一，只能解决 Stream.$OfInt/Function/Tuple<T,R> 问题的那种

编译期和运行期反射其实没有鸿沟。

我举个例子吧，调用任意f(int x,int y,..) 形式的函数，你可以用reflect，也就是把'f' cast成 f(Any..): Any ，也就是生成 = INSTANCE.f(a[0] as Int, a[1] as Int) as Any

确实，调用任意函数时这种as检查是必须的，但对 Proxy ，比如实现接口 { g(x: int) } ，拿 arg[0] 去调用f就不需要生成这个检查
上面的 curry 也是这个道理，只要把 <T1 T2 T3..> 放在接口里，编译期和运行期反射是一样的（比较难懂，因为java有泛型擦除）

但现在的AOP就用了类似的技巧去包装任意函数，其实只要把生成的代码缓存下来，就是你所说的模板。

（其实这就是 lang.invoke 的仅首次反射化啊。。没人看出来吗，相当于推理出某函数a[0]就是Int然后免检，invokedynamic调用啊）

就是说， callWithZero(obj::fn) 初次反射后，可以生成为一个重载， interface{字典} 可以生成为一个子类，没有模板和动态代理的问题了，反射能做到的业务都可以缓存为lib API

before&after的hook是一个道理

委托实现了C里的左值引用 bind(int& prop,Name)
interface by 实现了JS的原型链方法覆盖

var by可以视作反射赋值的轻量化，因为java确实不支持IntRef(0)这种东西，reflect.Prop又不直接

看来除了iterator，java的简化弄丢了另一个重要的框架基因

总感觉代理和DI是等价的，反射代理和codegen也一样，后者更麻烦

我之前的模式匹配trick 本质上也是var代理，只是var是匿

16 views02:46