[
https://issues.apache.org/jira/browse/THRIFT-3776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15227200#comment-15227200
]
artem antonenko edited comment on THRIFT-3776 at 4/5/16 9:57 PM:
-----------------------------------------------------------------
C#, Java and Obj-C that I use extensively all follow the same rules I propose
for Go. You can split your IDL into as much files as you want, put them in a
single namespace and everything will compile and work correctly. Every IDL file
is like a single translation unit. Go generator doesn't follow these rules so
either one of them should be fixed. Go looks like obvious choice because there
is no reason why it should be that way. There's no reason why multiple IDLs
with the same namespace would not work and it looks like poor design to not
allow that.
And I would understand if what you're describing works. But it doesn't. Once
your IDL gets somewhat big it practically unreadable and unusable in a single
file. For example, one of my projects has 109 thrift structures. I don't even
want to think about how it would work in a single file. And spliting it into
multiple namespaces wouldn't help at all because they're all part of a single
protocol. The resulting code would just be a mess of different namespaces just
so that Thrift could work with it. I know that because my Go project is also
somewhat big and first thing I tried is using different namespaces - does not
look great. Because of that I has a script that glues multiple IDL files into
one in the right order just because. Thank god the 109 structures project only
uses C#, Java and Obj-C and all of them support multifile IDL with the same
namespace.
And I want to emphasize the main point one more time - Thrift generators as
they're now are not designed to work only with one namespace-one file. There're
clearly written to support one namespace-multiple files. I can speak for C#,
Java and Obj-C - they compile AND work. I just tested every single generator
and the only ones that don't compile from multiple files are Go, Perl, Php.
Only 3 generators out of 21 are not compiling properly and put everything in
the file with the same name. Again, it looks like they should be fixed to match
the majority of other generators and not the other way around. And my PR does
that for Go. So the answer to "The alternative would be to provide a working
fix for every language supported by Thrift today" is - we only need to fix 3
languages because they're the only ones that don't work properly. Then we can
write tests for that case to make it official and finally put it to rest
was (Author: creker):
C#, Java and Obj-C that I use extensively all follow the same rules I propose.
You can split your IDL into as much files as you want, put them in a single
namespace and everything will compile and work correctly. Every IDL file is
like a single translation unit. Go generator doesn't follow these rules so
either one of them should be fixed. Go looks like obvious choice because there
is no reason why it should be that way. There's no reason why multiple IDLs
with the same namespace would not work and it looks like poor design to not
allow that.
And I would understand if what you're describing works. But it doesn't. Once
your IDL gets somewhat big it practically unreadable and unusable in a single
file. For example, one of my projects has 109 thrift structures. I don't even
want to think about how it would work in a single file. And spliting it into
multiple namespaces wouldn't help at all because they're all part of a single
protocol. The resulting code would just be a mess of different namespaces just
so that Thrift could work with it. I know that because my Go project is also
somewhat big and first thing I tried is using different namespaces - does not
look great. Because of that I has a script that glues multiple IDL files into
one in the right order just because. Thank god the 109 structures project only
uses C#, Java and Obj-C and all of them support multifile IDL with the same
namespace.
And I want to emphasize the main point one more time - Thrift generators as
they're now are not designed to work only with one namespace-one file. There're
clearly written to support one namespace-multiple files. I can speak for C#,
Java and Obj-C - they compile AND work. I just tested every single generator
and the only ones that don't compile from multiple files are Go, Perl, Php.
Only 3 generators out of 21 are not compiling properly and put everything in
the file with the same name. Again, it looks like they should be fixed to match
the majority of other generators and not the other way around. And my PR does
that for Go. So the answer to "The alternative would be to provide a working
fix for every language supported by Thrift today" is - we only need to fix 3
languages because they're the only ones that don't work properly. Then we can
write tests for that case to make it official and finally put it to rest
> Go code from multiple thrift files with the same namespace
> ----------------------------------------------------------
>
> Key: THRIFT-3776
> URL: https://issues.apache.org/jira/browse/THRIFT-3776
> Project: Thrift
> Issue Type: Improvement
> Components: Go - Compiler
> Affects Versions: 0.9.3
> Reporter: artem antonenko
>
> Currently compiler puts all generated Go code into two files - ttypes.go and
> constants.go. Because of that you can't compile multiple thrift files with
> the same namespace. They will just overwrite each other.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
