生成AS3 service 接口

[GoogleCodeExporter]

Branch name:
mail-as3-service
http://code.google.com/r/mail-as3-service/source/list

Purpose of code changes on this branch:
# 生成 as3 的 service interface，方便实现从另一端调用 as3 
提供的服务，另外已经据此实现了 rpc，见 
http://code.google.com/p/abu-rpc/source/browse/#svn%2Ftrunk%2Fsrc%2Factionscript
3

# 生成的代码见 
http://code.google.com/p/abu-rpc/source/browse/trunk/src/actionscript3/echo/src/
EchoService%24Interface.as 已经按之前的建议提供 done 
函数，提供异步返回结果的机制

# （与原实现不兼容之处）修改了 stub 类的命名，全部加了 
$Stub 后缀，例见 
http://code.google.com/p/abu-rpc/source/browse/trunk/src/actionscript3/echo/src/
EchoService%24Stub.as

# 按上次修改意见，已经修改了 writeIService 之类的函数。

When reviewing my code changes, please focus on:

After the review, I'll merge this branch into:
/trunk

Original issue reported on code.google.com by yonghaol...@gmail.com on 25 May 2012 at 2:59

[GoogleCodeExporter]

Main.java中删掉writeIService是很好的，在功能不变的情况下，减�
��了很多代码。

目前protoc-gen-as3中用到$字符的类名或者成员名都仅限内部生��
�代码使用，主要是为了避免和proto文件中定义的消息名或者��
�段名冲突

我希望外部使用的类名或成员名不出现$字符。因为：
1. 
Haxe的标识符不支持$字符，如果用了$字符就会导致Haxe不能使�
��protoc-gen-as3. 
支持Haxe一直是protoc-gen-as3的一个需求（虽然没在文档中明确��
�出）。而且，正巧我现在在做的游戏采用了Haxe。
2. 
Flex编码规范（http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conve
ntions）中的标识符命名都是不用$符号的。
3. 增加$Stub后缀破坏了向后兼容性。

此外，我想讨论一下service的服务端应该只支持异步风格的接�
��还是只支持同步风格的接口，还是两种风格都支持。因为我
没有用AS3实现service服务端的经验，我不清楚通常用AS3实现serv
ice服务端的需求到底是怎样的。我想聊聊用AS3实现service服务�
��的动机和用例。

最后，我看到“public var 
methods:Dictionary;”的代码，这种代码在每一个实例上初始化一�
��methods，浪费内存，不好。不如让每个生成的Service都实现以�
��IServerSideService中的callMethod函数，生成的代码就写个长长的sw
itch即可。

interface IServerSideService
{
  function callMethod(methodName:String, input:IDataInput, output:IDataOutput):void;
}

Original comment by pop.atry@gmail.com on 25 May 2012 at 5:31

[GoogleCodeExporter]

赞响应速度。

我同意去除 $ 字符。
但是我觉得 Stub 
类肯定还是要带一个后缀标明一下的（C++、java 和 Python 
的都有类似的标识），所以破坏对原有代码的兼容性是不可��
�免的，原因在于你之前的实现没考虑到对 AS3 实现 service 
的情况。我们可以商量一下使用 Stub 还是 _Stub 
作为后缀，达成共识。

“用AS3实现service服务端的动机和用例”这个问题我可以说一�
��，一是我项目使用的 abu-rpc 
的一个特点是双向调用，二是在网游中希望给服务器端一些��
�制客户端的便利。比如 bigworld 引擎的 rpc 
有个特性就是可以在服务器端调用一个函数，客户端图形界��
�会显示一个提示框，如提示服务器将于 5 
分钟后紧急维护等，这个特性也广泛用于我参与的 webgame 
项目。

我同意对 methods 进行优化，我会去做，然后会在新的 review 
中向你提交审核。

Original comment by yonghaol...@gmail.com on 25 May 2012 at 6:12

[GoogleCodeExporter]

不用急着修改。先应该搞清楚到底该用同步风格还是一部风��
�的函数定义吧。

我还想问个问题：服务端调用客户端函数时，需要等待客户��
�回应吗？

Original comment by pop.atry@gmail.com on 26 May 2012 at 12:40

[GoogleCodeExporter]

异步风格吧，反正异步风格也是很方便写代码的。
有此是需要客户端回应的，反正我们是通用代码生成，不能��
�结论说不存在需要等待客户端回应的呀。

Original comment by yonghaol...@gmail.com on 27 May 2012 at 11:57

[GoogleCodeExporter]

是不是像弹出对话框要用户选择“是”或者“否”这种需求��
�必须用异步风格？

Original comment by pop.atry@gmail.com on 27 May 2012 at 1:14

[GoogleCodeExporter]

我希望：
1. 
不破坏向后兼容性。也就是不使用_Stub后缀也没有_Interface后��
�。但如果需要生成接口，根据编码规范，可以有I前缀。
2. 
支持Haxe，即不能使用全局变量，也不能使用特殊字符作为变�
��名
3. 
在options.proto中增加选项以决定service的生成方式：生成服务端
service/生成客户端service/都生成/都不生成。为了保持向后兼容
性，默认选项是“生成客户端service”而不生成服务端service.

赖总觉得呢？

Original comment by pop.atry@gmail.com on 27 May 2012 at 2:40

[GoogleCodeExporter]

使用 I 前缀的风格我可以接受，但是 Stub 
怎么办？比如有一个叫 ChatService 的 proto，生成 
IChatService，然后实现为 ChatService，那它的 Stub 类就不能叫 
ChatService 啦，而且命名没有明确地表明它是一个 Stub 
的话，好像不是好的命名风格？
options.proto 中增加控制，我赞成。

Original comment by yonghaol...@gmail.com on 29 May 2012 at 2:38

[GoogleCodeExporter]

不是好的命名风格怎么讲？

Original comment by pop.atry@gmail.com on 3 Jun 2012 at 11:32

[GoogleCodeExporter]

我的意思是说 protobuf 生成的 java/cpp/python 类名都带有一个 
_Stub 后缀，不延续这种风格好像不是很好。
另外，我感觉生成的接口类用 I 
前缀好像也有问题，因为它实际上是一个 class，不是 interface 
噢，用 I 前缀容易让人误会。
综上，我觉得还是加上 _Stub 和 _Interface 后缀好了。你看呢？

Original comment by yonghaol...@gmail.com on 4 Jun 2012 at 1:29

[GoogleCodeExporter]

Original comment by pop.atry@gmail.com on 6 Jun 2012 at 9:52

• Changed state: Fixed