[ 
https://issues.apache.org/jira/browse/THRIFT-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624921#action_12624921
 ] 

David Reiss commented on THRIFT-122:
------------------------------------

I am familiar with Java and Python and I have found the use of heterogeneous 
collections to be extremely rare.  The problem is that it is so hard to write 
code to deal with a collection that might contain a combination of number, 
strings, lists, and objects.  You effectively have to do a switch statement on 
every element, which makes for unwieldy code.  The only compelling use case 
that I'm aware of is a collection of a superclass type where the individual 
objects are of different subclasses.  This works cleanly because of virtual 
methods.  However, no Thrift types support virtual methods, so this case does 
not apply to Thrift.  If you want to explain your use case in more detail, you 
might be able to convince me that this feature is "extremely important".  
Otherwise, I will continue to argue against a feature that I consider to be 
adding a harmful amount of complexity to Thrift.

> 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.

Reply via email to