The future plan of JSObject

[zombieyang]

起初，JSObject只是为了满足一个需求存在的：开发者需要在C#侧暂存一个JS对象，并在未来的某个时刻传回JS。

但后续其实发现有挺多需求也能由JSObject完成，比如：

1. 在C#侧将一个IEnumerable转换成JS数组（由JSObject来代表）。这样就不需要在JS侧做转换了。
2. 代表一个JSFunction，并在后续某个时刻在C#侧就可将其转换成delegate。
3. 从一个大JSObject中取出里面的Value（主要用于ESModule的运行结果获取）

本帖将继续记录jSObject的相关需求，可能会在未来的某个时刻对它进行大重构实现。

[watsonsong]

感觉JSObject应该有类似LuaTable的功能。
这样诸如JsBehaviour的实现似乎可以更直接一点，‘JsStart’等可以直接从JSObject里面去查询到，而不用把JsBehaviour里面的JsStart的字段导出给JS，再由JS反向设置进去。

另外应该有显式的Dispose，而不是只依赖C#的析构函数去释放资源。

[zombieyang]

显式Dispose的需求是？
这样好像就得自己保证C#没有其它引用它的地方了

[watsonsong]

可以参考xlua里面的LuaTable.Dispose。如果业务逻辑自己知道这个对象不需要，主动Dispose能够更快下降内存。否则要等C#的内存GC，才能清理掉一个js的对象。

[watsonsong]

另外有一个痛点是比较缺乏数组在语言边界传递的能力。
C#获取js的对象，无论是JSObject上注释掉的Get接口获取一个数组，或者Eval<string[]>这样的形式都获取不了。只有转json字符串或者ArrayBuffer再去解析。
js获取C#的数组，也必须在js里面手工写一个循环才能把C#的数组转成js的。但作为一个常见能力如果能native高效的支持就好了。