Hi, I consider this behavior a bug because I'm surprised when it happens. Because PHP 'normally' does implicit type casting and most functions don't use referenced arguments, I assume the argument I pass to the service function won't change, because this will happen in most of the cases.
But when I pass a variable to a function like settype(), I assume that this will change the type, because it's the nature of the function to do so. Also when I'm using a function like system(), it makes sense to have a referenced output variable, because the nature of the function dictates that the output variable will be filled with the output of the executed command. I don't know why references are used, but it I guess they are cheaper, performance and memory wise. Kind regards, - Anner. -- Anner van Hardenbroek [email protected] On 1 jun 2010, at 14:03, Oleg Grenrus wrote: > Hi, > > recently we encountered a problem with thrift_protocol PHP-extension: > it takes parameters "by-reference" and casts them into proper types. > > Probably example will explain what is possibly wrong: > > <?php > $str = 100; > var_dump($str); > echo rtrim($str), "\n"; // expects string > var_dump($str); > ?> > > and output is as expected, type of $str isn't changed > > int(100) > 100 > int(100) > > > But consider we have Thrift service with function specified as: > > void foo(1:string s) > > and we use it similarly > > <?php > // ... initialize thrift > $str = 100; > var_dump($str); > $client->foo($str); > var_dump($str); > ?> > > results > > int(100) > string(3) "100" > > => type of $str is changed! > > I looked through the extension code and there's convert_to_* calls on the > input > variables, which causes this suprising behaviour. I also tried to replace > convert_to_* calls in binary_serialize with _ex counterparts, but something > went completely wrong. > > Is this expected behaviour or should this be considered as a bug? > > > -- > Oleg Grenrus
