[jira] [Commented] (THRIFT-342) PHP: can't have sets of complex types

["Nicholas Telford (JIRA)" <ji...@apache.org>]

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

Nicholas Telford commented on THRIFT-342:
-----------------------------------------

A hybrid approach would be to look at the type of data in the set, if it's a PHP primitive use an array (with array_unique) and if it's an object (Thrift struct) use [SplObjectStorage|http://php.net/SplObjectStorage]. The latter only works with objects (ruling it out as a blanket solution) but is apparently better performing than arrays for storing sets of objects. (see http://technosophos.com/content/set-objects-php-arrays-vs-splobjectstorage)

Since SplObjectStorage implements ArrayAccess as of PHP 5.3.0, it will behave as if it were an array in most important respects. But not entirely. (e.g. usages of array_* functions)

I'm unfamiliar with the generator code, so I'm not sure I'll be able to roll a patch for this myself. Is it even possible to have it generate different code depending on the type being stored in the set?

It's not ideal, but it wouldn't be a regression for primitives and would at least provide an implementation for users.

> PHP: can't have sets of complex types
> -------------------------------------
>
>                 Key: THRIFT-342
>                 URL: https://issues.apache.org/jira/browse/THRIFT-342
>             Project: Thrift
>          Issue Type: Bug
>          Components: PHP - Compiler, PHP - Library
>         Environment: SVN trunk r743881
>            Reporter: David Sklar
>         Attachments: thrift-342.patch
>
>
> A setup like this:
> struct alice {
>   1: string bob
> }
> and another like this:
> struct charlie {
>    1: set<alice> david
> }
> causes problems because the generated PHP code looks like:
> ==
>         case 1:
>           if ($ftype == TType::SET) {
>             $this->david = array();
>             $_size0 = 0;
>             $_etype3 = 0;
>             $xfer += $input->readSetBegin($_etype3, $_size0);
>             for ($_i4 = 0; $_i4 < $_size0; ++$_i4)
>             {
>               $elem5 = null;
>               $elem5 = new alice();
>               $xfer += $elem5->read($input);
>               $this->david[$elem5] = true;
>             }
>             $xfer += $input->readSetEnd();
>           } else {
>             $xfer += $input->skip($ftype);
>           }
>           break;
> ===
> Using objects as array keys makes PHP cranky and the values can not be properly set. I think the solution to this is either:
> 1. Document that the PHP bindings do not support sets of complex types. (boooo!)
> 2. Modify the generated code so that the values are stored in array values not keys. (With some additional checks to ensure uniqueness, or perhaps just using spl_object_hash($theObject) as the array key.
> This seems similar to the issues raised in THRIFT-231 and THRIFT-162
>               $this->david[$elem5] = true;

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira