jonny91 / protoc-gen-as3

Automatically exported from code.google.com/p/protoc-gen-as3
BSD 2-Clause "Simplified" License
0 stars 0 forks source link

生成AS3 service 接口 #33

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
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 commented 8 years ago
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 commented 8 years ago
赞响应速度。

我同意去除 $ 字符。
但是我觉得 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 commented 8 years ago
不用急着修改。先应该搞清楚到底该用同步风格还是一部风��
�的函数定义吧。

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

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

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

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

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

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

GoogleCodeExporter commented 8 years ago
我希望:
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 commented 8 years ago
使用 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 commented 8 years ago
不是好的命名风格怎么讲?

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

GoogleCodeExporter commented 8 years ago
我的意思是说 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 commented 8 years ago

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