Closed GoogleCodeExporter closed 9 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
赞响应速度。
我同意去除 $ 字符。
但是我觉得 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
不用急着修改。先应该搞清楚到底该用同步风格还是一部风��
�的函数定义吧。
我还想问个问题:服务端调用客户端函数时,需要等待客户��
�回应吗?
Original comment by pop.atry@gmail.com
on 26 May 2012 at 12:40
异步风格吧,反正异步风格也是很方便写代码的。
有此是需要客户端回应的,反正我们是通用代码生成,不能��
�结论说不存在需要等待客户端回应的呀。
Original comment by yonghaol...@gmail.com
on 27 May 2012 at 11:57
是不是像弹出对话框要用户选择“是”或者“否”这种需求��
�必须用异步风格?
Original comment by pop.atry@gmail.com
on 27 May 2012 at 1:14
我希望:
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
使用 I 前缀的风格我可以接受,但是 Stub
怎么办?比如有一个叫 ChatService 的 proto,生成
IChatService,然后实现为 ChatService,那它的 Stub 类就不能叫
ChatService 啦,而且命名没有明确地表明它是一个 Stub
的话,好像不是好的命名风格?
options.proto 中增加控制,我赞成。
Original comment by yonghaol...@gmail.com
on 29 May 2012 at 2:38
不是好的命名风格怎么讲?
Original comment by pop.atry@gmail.com
on 3 Jun 2012 at 11:32
我的意思是说 protobuf 生成的 java/cpp/python 类名都带有一个
_Stub 后缀,不延续这种风格好像不是很好。
另外,我感觉生成的接口类用 I
前缀好像也有问题,因为它实际上是一个 class,不是 interface
噢,用 I 前缀容易让人误会。
综上,我觉得还是加上 _Stub 和 _Interface 后缀好了。你看呢?
Original comment by yonghaol...@gmail.com
on 4 Jun 2012 at 1:29
Original comment by pop.atry@gmail.com
on 6 Jun 2012 at 9:52
Original issue reported on code.google.com by
yonghaol...@gmail.com
on 25 May 2012 at 2:59