Re: defining a global object table
| From: | J. Adams | Date: | Sat, 12 Nov 2011 01:56:18 +0000 |
| Subject: | Re: defining a global object table | ||
| References: | 1 2 3 4 | Groups: | php.pecl.dev |
| Request: | Send a blank email to pecl-dev+get-8858@lists.php.net to get a copy of this message | ||
Thanks for responding, Johannes -- I know there's plenty going on at the moment.
As I pointed out in my prior message, the var_hash approach does not work correctly on the example you sent (at least not in php 5.3.8).
On 11/11/2011 4:58 PM, Johannes Schlüter wrote:
Hi, On Tue, 2011-11-08 at 15:46 -0800, J. Adams wrote:Thank you, Johannes, for the your response. I'm really grateful to have access to the guys who know the ins and outs here. I'm having some difficulty understanding how your example necessitates the php_add_var_hash approach in var.d that you have recommended. IMy main point was about not using a global variable and I pointed to the var_hash approach as a proven working example.appreciate you pointing out situations that will result in weird behavior and I believe the example you provided could cause a problem because code execution switches back and forth between PHP and C execution. From your example:Mixing PHP and C doesn't matter.<?php serialize($data); ?> This results in the traditional serialize function (implemented in C) being called on the array, $data.If I got your idea correct here you will fill your global list.When the recursive serialization logic reaches $data[0], with a member var pointing to an instance of class A, control is handed to the method A::serialize (defined in PHP) which in turn calls some serialization function (base64_encode, serialize, amf_encode, whatever). Because of the transfer of execution from PHP to C and back to PHP and back to C, the original object might be serialized separately as distinct copies rather than with proper object references.This second serialization will refer to your previous global variable and manipulate it in some way (either reinitialize or compare with values in there) Once the inner iteration ends and the outer iteration continues it will continue using your global variable assuming the old state but will be modified from the inner iteration. So don't use global variables but pass the context along. Global variables are bad. The var_hash approach shows a way that works.If I'm not mistaken, the approach I suggested will avoid infinite recursion by recognizing that a prior object has been encountered basedInfinite recursion is no issue in this example. johannes