[
https://issues.apache.org/jira/browse/THRIFT-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624958#action_12624958
]
David Reiss commented on THRIFT-122:
------------------------------------
If a user is deploying code for their own request handler, couldn't they also
deploy the generated code needed to [de]serialize it? If a client is willing
to write code to handle a given type of response, wouldn't they be willing to
build the generated code to [de]serialize it? I would posit that will such a
large variety of types, you might actually be better served by having them all
defined in one authoritative IDL file (or a set of files) rather than having to
maintain documentation for what fields are present and what types they might
have, especially when that documentation can easily get out of date. Also,
having statically-typed data will make your code (both the [de]serialization
code and the application code) faster, and you seem to be quite concerned with
efficiency.
However, assuming that you are, for whatever reason, unable to change your data
model, allow me to explain the variant idea that was previously discussed on
the old mailing list. A "variant" would be a type that would be encoded on the
wire as a structure with a single field. The field would either be a number, a
string, a list of variants, or a map from strings to variants (this could be
tweaked a bit). Any language that can't properly represent a variant (or
hasn't implemented it yet) can safely skip it because it is wire-compatible
with a structure. A language that does support variants would represent it in
memory in the most natural way possible. I know you said that backwards
compatibility is not a concern *for you*, but this design has the benefit that
it can be fairly easily implemented in a language that does not support the
full compact protocol. It also supports a few more use cases than heterogenous
collections, while adding less complexity (I think) to Thrift's data model.
Therefore, I think it is a better feature for us to try to implement. (And it
seems like it would cover your use case as well.)
It is actually possible for variants to contain structs as well while
preserving compatibility, but it is pretty much impossible to implement in C++
and in other languages it would either require some sort of global registry of
Thrift types (which I am opposed to) or instantiating a class by name (which is
both tricky and inefficient). I would request that anyone requesting the
feature of mixing statically and dynamically typed data in this way think long
and hard about whether it is truly necessary and how to implement it cleanly is
several languages.
> Allow heterogeneous collections
> -------------------------------
>
> Key: THRIFT-122
> URL: https://issues.apache.org/jira/browse/THRIFT-122
> Project: Thrift
> Issue Type: New Feature
> Reporter: Noble Paul
>
> Currently thrift only supports homogeneous collections . But , that is very
> restrictive for many languages which allows heterogeneous collections. It
> does not have to be supported in BinaryProtocol The new DenseProtocol may add
> support for this
> implementation details
> the IDL can allow syntax
> {code}
> list<?>
> set<?>
> map<?,?>
> map<?,the-type>
> map<the-type,?>
> {code}
> While writing down data use a type modifier to say whether key (1), value(2)
> or both(3) are wild cards
> for a List/Set use a type modifier 1 to specify that it is heterogeneous
> If it is a homogeneous collection do it the way it is done now.
> Or else
> add type information just before the data. So it adds an extra byte/element
> For ma
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
