Re: Serializing references - part I

On Tue, 24 Oct 2000, Stanislav Malyshev wrote: > SS>> This can be improved by making the interface independent from > SS>> the implementation. As your patch shows, changing the > SS>> implementation requires changes all over our codebase which > SS>> should not be necessary in the ideal case. > > Well, you should build the hash somewhere. You cannot do it in > php_var_serialize, since it's recursive. What do you propose? I can make > another layer below php_var_serialize, but this will mean I could not use > the same hash for a number of vars, which is desirable for sessions. > Do you have some other proposal? I'm talking about the interface, not about additional layers or real changes in your implementation. So, instead of writing HashTable var_hash; zend_hash_init(..); php_var_(un)serialize(..); zend_hash_destroy(..); we would use php_var_hash_t var_hash; var_hash = var_hash_init(); php_var_(un)serialize(..); var_hash_destroy(var_hash); This would be a one-time change in our code. Future implementation changes would require no changes in the interface. > Otherwise, there's no point in it. What was the problem? If you have $foo > and $var being reference-bound, and register both, you lose the > binding. If you register only one, you lose binding in any case, just > because other one won't exist in time of next request. So, naturally, > preserving references would span only on serialized > (registered) variables. Any idea why this drops the property n? class foo { var $ok = "yes"; } $c = new foo; $c->n = &$c; print serialize(&$c)."\n"; print $c->n->ok."\n"; Output: O:3:"foo":2:{s:2:"ok";s:3:"yes";} yes - Sascha