duangsuse::Echo

#Learn #OOP #js #design #Java #Kotlin
duangsuse:
大失败，不会写了；第一次还觉得需要 RingBuffer 或者双指针维护缓冲器那样……

其实根本没有那么麻烦， post 的时候带上 queue index ，全部完成右移视口 offset 就够了，如果没全完成右移也不行
简单设计复杂化

许久没有编程的动苏眼高手低到了这样的程度，不行，一定要写出来刚才那个的核心逻辑😡

……草，竟然真的可以用了，虽然没测试原来 runtime.Port 真的像 channel 一样要 sender自己 onMessage 也能收到，所以要先 verify 吗

基础封装的逻辑就是封装 channel ， create server 可选， client 一定；兼容了 DOM postMessage API

假定 Function 的 que 无法共享，利用 seqNum (传输侧别名为 no) 指代响应目标，然后 que 本身利用 offsetL 压缩一下，不会一直增长
核心部分 20 行

仔细想想这个封装的确很有必要，总体 post/onMessage 请求一次 backend 是 callback(proc(msg)) ，C/S 两边都要 post,onMessage,msg,post 还难复用信道，call 了服务端处理完还要尝试按原名回调，容易重复标识符数据。

Jack Works:
来，把异常处理也加上

duangsuse:
Uncaught DOMException: The object could not be cloned.
不得不想序列化变形的办法…… 而且 JS 还是弱类型

好吧，好像需要一个完整的序列化方法，这个方法必须介入 sendMessage 数据来允许保留类型信息，如果不止要存留 Error message 的话 🌚

Jack Works:
到最后你会发现你重新发明了 JSON RPC

所以我把我的实现改造成了 JSON RPC 做成了通用的库

duangsuse:
serialize 本来就应该是框架层做的，而且它也只需要暴露 ser() deser() 两个函数而已
我们只不过应该在框架上写个十来行的小程序就够了

Jack Works:
我也是这么设计的啊， https://jack-works.github.io/async-call-rpc/async-call-rpc.asynccalloptions.html

duangsuse:
中国开发者越来越难了， github.io 都不能用了 #China #net #Freedom

以后写个软件第一关过政审第二关过苹果 Steam 的审，层层加码，服！

duangsuse:
累死了，反正能用就行
格局小了，我本来准备写 DOM 动画的，又鸽子了，再鸽就溢出了……

又到了各种 push 不上去的时间段，中国的网络环境。

Jack 那个我是真的摸不清，骨架太大了，重写人的脑力也是有限的(当然 typing 应该看得懂就是各种 scope feature 看不懂)，知道 onConnect,disconnect 这些 API 也不好分析
不过好歹是能用一个，虽然肯定有性能开销了

Jack Works:
里面逻辑复杂但是外面接口简单啊

duangsuse:
动苏的标准是从内到外没有业务主干外的代码，如果有就作为插件嵌在骨干外…… 总之就是一句话，强调最根本最必须的算法 #statement

Jack Works:
你只要写一下怎么收发消息的逻辑，我这个框架就能 magically 跑起来

duangsuse:
所以说动苏的编程风格是函数式改 upvalue 而不是 class 属性，因为我强调算法先于架构

Jack Works:
动苏？啥玩意 = =

rxliuli:
你的中文昵称？

Jack 更喜欢在一个文件中编写多个 func，然后全部命名导出，吾辈更倾向于 class method 的形式

Jack Works:
我这个对 tree shake (webpack) 比较好🤔

duangsuse:
是的， duang 源于成龙洗发液的“头发动啊”，suse 是 Linux 发行，所以叫『动苏』😋 #life

动苏会觉得自称「我」或者「咱」(代替「我们」，我w键坏了) 有点生硬，这样就好很多

duangsuse:
这一点我还是倾向 Jack ，毕竟 Java 算是八股文式 OOP ，没有为实际编程有 toplevel func 样的优化

我可没说错话哦，面向对象的 class 本质是对函数式闭包加类型， property 即 upvalue ， method 即子程序化分段，整个对象即 send(name,args) 元方法，真正的面向对象只有「物/例」和其上的名词动词，没有文绉绉的废话甚至混乱 static。 #statement

面向对象把数据和其上操作混合定义是好事，可惜某些人就知道装B 起一大堆半通不通的专有名词，专业术语往往鬼用没得，给人们的思考造成一大堆麻烦。

要是 OOP 最初的作者能有半点实用化的觉悟，绝对不会放任 Jawa 混乱善良合理的编程习性

rxliuli:
但 Java 确实流行起来了而且基本被大规模实用了。。。虽然写起来确实感觉不太舒服，尤其是写过其他更好的语言之后

duangsuse:
所以说它才有机会被 Kotlin 吊打啊~
可惜 JavaEE 是他们自己搞出来自以为高明的八股文，很多 Kotliner 还没做好准备击败他们

CodeHz 📡:
(因为用类作为天然的命名空间分割函数的方法太好了（

duangsuse:
是的，构造器就像可覆写的一个局部变量初始化 header
然后整个类就像一个函数， constructor 提供了初始的变量混入

CodeHz 📡:
(oop 很好)就是无法自然的表达多重dispatch

duangsuse:
polymorphism 多态不可以吗？

<就有个主次之分了，而且也不是运行时多态

运行时多态上 Sum type 可以 Visitor 啊，也挺方便的

<（有好几个参数需要动态分发的时候写起来还是挺别扭的

c 里搞 tagged union 到处 cast 就不方便吧…… 每个使用处都要检测 tag
请教下什么叫多派发啊

<大概就是这种（ https://en.wikipedia.org/wiki/Multiple_dispatch

C#是直接用动态运行时（DLR)了 #dotnet

类似 #Haskell 的 pat match 啊，那样 visitor 的确就不够了，得 trie 数据结构匹配...

非常疯狂，看起来 A.collideWith(B) 和反过来 B,A 是一样的

看起来是个非常有意思的特性，不过我感觉离算法/设计模式比 PLT 近些， visitor 单判定派发更实用一些

Wikipedia

Multiple dispatch

feature of some programming languages

91 viewsduangsuse, edited 14:47