service.lua 这个设计的用途是？以函数的形式构造一个服务？

[Gowa2017]

虽然看得起来有用，但暂时还没有想到什么场景一定要用这个东西。

但我看 sharetable 服务就是用它来实现的。

[cloudwu]

方便把东西写到一个文件里，提问题时好贴代码。

[Gowa2017]

方便把东西写到一个文件里，提问题时好贴代码。

这样理解是否正确：

1. 常规情况下 skynet 需要一个服务脚本，然后用 skynet.newservice 调用。
2. 发消息的话需要 skynet.call/send，而采用 service 的形式，就可以把一些常用的消息指令（当然也有其他代码），封装到库，就不需要分开了。

[cloudwu]

另一个不可取代的功能是：当你想用 meta 的方式构建服务，比如用代码生成服务代码，或者在集群中，服务的代码是通过集群节点跨节点传输过去的。那么静态文件就不行了。

[Gowa2017]

另一个不可取代的功能是：当你想用 meta 的方式构建服务，比如用代码生成服务代码，或者在集群中，服务的代码是通过集群节点跨节点传输过去的。那么静态文件就不行了。

感谢。我看了一下代码，对于 service 服务的实现，是将函数用 string.dump 导出成二进制，然后来构造服务的。那么我有一个业务场景：
比如我在定义游戏对象（若角色）的属性时，某些属性（常见的二级属性依赖一级属性）的时候，二级属性我会给他定义一个 formula，其中定义了它的依赖和计算公式。那我是否依然可以用这种形式，在多个战斗服务间用 sharetable 共享这个二进制导出的 formula（sharetable，也就是您为 LUA 打的补丁无法直接共享函数），而不用操心每个服务需要单独的加载那些规则了（在我的的游戏只是MUD类似，不是太大的那种）。

[cloudwu]

sharetable 是一个 trick ，用来解决不变数据的共享时性能问题。它不应该变成同步数据的常规手段。

解决问题应该优先考虑常规手段，你这个问题用 rpc 把需要的数据传递过去同步就够了。

[Gowa2017]

sharetable 是一个 trick ，用来解决不变数据的共享时性能问题。它不应该变成同步数据的常规手段。

解决问题应该优先考虑常规手段，你这个问题用 rpc 把需要的数据传递过去同步就够了。

云大，我再次看了一下 sharetable 的代码，实际上，您是让他可以支持没有上值的 Lua 函数共享的。那么，对于这种没有上值的 纯 函数，我就可以让他给共享起来了。