[jira] [Commented] (THRIFT-3595) Perl Bindings: Set serialization/deserialization differs

["David Morel (JIRA)" <ji...@apache.org>]

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

David Morel commented on THRIFT-3595:
-------------------------------------

I have some doubts about this, partly because of the difficulty of implementing real sets in perl, partly because of my ignorance of the Thrift code base (and the generator looks scary, to be honest :-)
Using a hashref as is typical to emulate sets in perl will indeed be troublesome since any value will be cast or flattened to a string when used as a key, thus rendering deserialization impossible for objects, so I suspect we should keep using arrays. However, array operations like uniq that we could use to guarantee uniqueness of values will not work in case of mixed value types: say you have @foo = (1, "1"), which one could consider distinct, List::MoreUtils::uniq and friends will consider these a single value when comparing them.
So I don't know if this is important or not; should a set contain only values of the same type (as is the case in most languages) or should it allow a mix of numeric, strings, objects or whatever, in which case we will encounter casting issues.
If we're going for that case, there could be a creepy solution: use a hash(ref) but using a serialized version of the variables (including objects) as keys, with Storable::freeze for instance. You'd guarantee type safety and you could get back the original values on deserializing the keys (including a dangerous use of eval for restoring objects.
Even though this solution would work, I wouldn't be a firm supporter of it (other than for its cuteness for which non-perlers would have a different name ;-) unless really necessary.
So, to sum it up, what is it exactly we're trying to achieve? 


> Perl Bindings: Set serialization/deserialization differs
> --------------------------------------------------------
>
>                 Key: THRIFT-3595
>                 URL: https://issues.apache.org/jira/browse/THRIFT-3595
>             Project: Thrift
>          Issue Type: Bug
>          Components: Perl - Compiler
>    Affects Versions: 0.9.1, 0.9.2, 0.9.3
>            Reporter: Adam Millerchip
>
> In the Perl bindings, a Thrift Set is dezerialized as a hashref, but the serialization code expects an arrayref. This causes the code to die when called if attempting to serialize a previously dezerialized Set.
> Additionally, it looks like there is a typo in the test that is testing this feature:
> https://github.com/apache/thrift/blob/49f4dc0cd8c87213a0f80ae1daba2d094a358ea7/test/perl/TestClient.pl#L262
> If you change that {{@$setout}} to {{@$setin}}, the test fails.
> It doesn't make much sense to implement a Set in Perl as array, because arrays allow duplicate entries and are ordered.
> I've written a change for the serialization that correctly expects a hashref: https://github.com/apache/thrift/pull/831



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)