You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Vitali Lovich (JIRA)" <ji...@apache.org> on 2014/10/08 00:10:33 UTC
[jira] [Updated] (THRIFT-2772) reduce manual maintenance required
for cpp_type & cpp_include
[ https://issues.apache.org/jira/browse/THRIFT-2772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vitali Lovich updated THRIFT-2772:
----------------------------------
Description:
If I want to reference thrift types in a custom unordered_map currently:
{{
// foo.thrift defines Foo
namespace cpp me::thrift::foo
// bar.thrift defined Bar
namespace cpp me::thrift::bar
// foobar.thrift
namespace cpp me::thrift
include "foo.thrift"
include "bar.thrift"
cpp_include "<unordered_map>"
message Foobar {
map cpp_type "std::unordered_map<foo::Foo, bar::Bar>" <Foo, Bar> mapping;
}
}}
Downsides:
* Requires me to have a good rule for generating package names from the get-go.
* If I change the namespace name, I have to know *all* the spots to update it.
* If I change the type name, I have to modify it in an extra spot that's not validated by the compiler.
* I have to duplicate the cpp_include statement across all thrift files & know the mapping.
A more maintainable mechanism would be a type-mapping file supported by the compiler.
{{
type UnorderedMap<T1, T2> {
cpp_include = "<unordered_map>"
cpp_type = "std::unordered_map<$T1, $T2>"
java_type = "java.util.HashMap"
}
Then:
include "UnorderedMap.thrift"
message Foo {
UnorderedMap<T1, T2> foo;
}
was:
If I want to reference thrift types in a custom unordered_map currently:
// foo.thrift defines Foo
namespace cpp me::thrift::foo
// bar.thrift defined Bar
namespace cpp me::thrift::bar
// foobar.thrift
namespace cpp me::thrift
include "foo.thrift"
include "bar.thrift"
cpp_include "<unordered_map>"
message Foobar {
map cpp_type "std::unordered_map<foo::Foo, bar::Bar>" <Foo, Bar> mapping;
}
Downsides:
1) Requires me to have a good rule for generating package names from the get-go.
2) If I change the namespace name, I have to know *all* the spots to update it.
3) If I change the type name, I have to modify it in an extra spot that's not validated by the compiler.
4) I have to duplicate the cpp_include statement across all thrift files & know the mapping.
A more maintainable mechanism would be a type-mapping file supported by the compiler.
type UnorderedMap<T1, T2> {
cpp_include = "<unordered_map>"
cpp_type = "std::unordered_map<$T1, $T2>"
java_type = "java.util.HashMap"
}
Then:
include "UnorderedMap.thrift"
message Foo {
UnorderedMap<T1, T2> foo;
}
> reduce manual maintenance required for cpp_type & cpp_include
> -------------------------------------------------------------
>
> Key: THRIFT-2772
> URL: https://issues.apache.org/jira/browse/THRIFT-2772
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Compiler, Compiler (General)
> Reporter: Vitali Lovich
>
> If I want to reference thrift types in a custom unordered_map currently:
> {{
> // foo.thrift defines Foo
> namespace cpp me::thrift::foo
> // bar.thrift defined Bar
> namespace cpp me::thrift::bar
> // foobar.thrift
> namespace cpp me::thrift
> include "foo.thrift"
> include "bar.thrift"
> cpp_include "<unordered_map>"
> message Foobar {
> map cpp_type "std::unordered_map<foo::Foo, bar::Bar>" <Foo, Bar> mapping;
> }
> }}
> Downsides:
> * Requires me to have a good rule for generating package names from the get-go.
> * If I change the namespace name, I have to know *all* the spots to update it.
> * If I change the type name, I have to modify it in an extra spot that's not validated by the compiler.
> * I have to duplicate the cpp_include statement across all thrift files & know the mapping.
> A more maintainable mechanism would be a type-mapping file supported by the compiler.
> {{
> type UnorderedMap<T1, T2> {
> cpp_include = "<unordered_map>"
> cpp_type = "std::unordered_map<$T1, $T2>"
> java_type = "java.util.HashMap"
> }
> Then:
> include "UnorderedMap.thrift"
> message Foo {
> UnorderedMap<T1, T2> foo;
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)