嵌套IPC对象数组

[Zhuangkh]

[IpcPublic]
interface IFoo
{
	List<IFoo2> Foo2s { get; set; }
}
[IpcPublic]
interface IFoo2
{
	...
}

IpcPublic为了生成实际的代理对象，所以只能标在接口上，而上面这种写法是无法序列化的，是否意味着嵌套IPC对象数组是行不通的？

有没有什么可供尝试的思路

[walterlv]

这个问题没有想象中那么容易🤔

---

想了解你的业务需求是什么？

因为要完成 Ipc 对象集合，所做的事情可大可小。小至专门支持 Ipc 对象的常见集合类型，大至支持 Ipc 和序列化对象的相互嵌套（例如列表、字典、元组等）。

根据业务需求，看看我们做到哪种程度就够，不然工作量太大了。

---

解决这个问题的关键是修改 Garm 类型（Generated Arguments and Return Model），源生成器会为 IpcPublic 接口中的每一个参数和每一个返回值生成一个 Garm 对象，用来存储对应参数或返回值的元数据（仅 Ipc 需要的那些）。原本 Garm 只能表示要么纯 Ipc 对象，要么可序列化对象；现在可以考虑改成：

1. 还额外记录这是否是一个 Ipc 对象的集合
2. 或者终极改成一个更复杂的对象，能分析出这个复杂嵌套的参数或返回值的可序列化成分和 Ipc 对象成分

方案 1 几乎不怎么改动现有的设计。方案 2 可能是一个挑战，并不是说不能做，而是我们还希望在支持的同时仍拥有不错的性能。

[Zhuangkh]

我有一个外部依赖库是.Net Framework的，有个新的.Net项目想用上旧的代码，我在尝试把外部依赖库的调用挪到一个独立的.Net Framework，用IPC对象传递出去，IPC对象集合是想保持和原依赖库的类设计相似。

昨天翻了一下源码，想法也是方案1，只做简单支持IPC对象集合，改动小，对性能影响也小点。

当然最直接粗暴的做法是，不公开这个IPC对象集合，利用可序列化的参数去返回具体某一个集合成员（IPC对象），再去调用。

这个issue的目的还是从库设计的角度探讨一下有没有实现的必要以及实现可能的路径，感谢解答😚😚