[
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)
