[jira] Issue Comment Edited: (THRIFT-122) Allow heterogeneous collections

["Noble Paul (JIRA)" <ji...@apache.org>]

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

noble.paul edited comment on THRIFT-122 at 8/22/08 11:04 AM:
-------------------------------------------------------------

bq.I am familiar with Java and Python and I have found the use of heterogeneous collections to be extremely rare

If you ever use Solr you will see how useful that is.  The output object is one huge mix of collection objects. 
In our organization we tend to use a mix of collections to pass around data. 

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

There are only a finite no:of types to deal with in any structure basic+ struct types. I'll be surprised to see if there are a total of more than 25 types. out of those,  15 are known types(primitives) so they do not have to be there in the generated code they can be in the runtime code. Say you have around 10 custom types . So a switch with 10 cases really is not that complex.  Take a look at the readVal() in [this class | http://svn.apache.org/viewvc/lucene/solr/trunk/src/java/org/apache/solr/common/util/NamedListCodec.java?revision=685640&view=markup ] this is our custom binary format. 





      was (Author: noble.paul):
    bq.I am familiar with Java and Python and I have found the use of heterogeneous collections to be extremely rare

If you ever see use Solr you will see how useful that is.  The output object is one huge mix of collection objects. 
In our organization we tend to use a mix of collections to pass around data. 

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

There are only a finite no:of types to deal with in any structure basic+ struct types. I'll be surprised to see if there are a total of more than 25 types. out of those,  15 are known types(primitives) so they do not have to be there in the generated code they can be in the runtime code. Say you have around 10 custom types . So a switch with 10 cases really is not that complex.  Take a look at the readVal() in [this class | http://svn.apache.org/viewvc/lucene/solr/trunk/src/java/org/apache/solr/common/util/NamedListCodec.java?revision=685640&view=markup ] this is our custom binary format. 




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