Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:68334 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 83320 invoked from network); 29 Jul 2013 20:34:34 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 Jul 2013 20:34:34 -0000 Authentication-Results: pb1.pair.com header.from=jakub.php@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=jakub.php@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.43 as permitted sender) X-PHP-List-Original-Sender: jakub.php@gmail.com X-Host-Fingerprint: 209.85.216.43 mail-qa0-f43.google.com Received: from [209.85.216.43] ([209.85.216.43:49774] helo=mail-qa0-f43.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 3A/13-62183-9D1D6F15 for ; Mon, 29 Jul 2013 16:34:33 -0400 Received: by mail-qa0-f43.google.com with SMTP id cl20so1950983qab.9 for ; Mon, 29 Jul 2013 13:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=qqsfdrqy2FTOXf+ZK4udHgSU0BRvKGLsIP9vRWe954U=; b=ws5qm10z4Mbx546MUQoL+BIYfH4xSWjAk2hpYFUGdJilL9Mc68aK+PBPjWZAlKYvL0 sE4UmJs88ZufTW4IXuPFnD6v8qUMeJhmIfABiRB5TOXKbaeqadvFQO47oVzv4uF//FKR a0mWT+yvx/Q8HEQ2c4yMNZNnvJsHAIbR5sjo7iIswWvW/xTQ1yXWMY7ni6ioIT5YjmR0 Ys7T1oqJiHfqY38P03mdIqlSnpppdvGyUFFMLHnLwaKH2NuyC+NSl6IGVybBsO3H3dIN hOfbYCHPOwx/F8B8g7NrglHYaIMN+oWOKYcJelHBIt2htV/oFE2n6c0XITSoTFirhWOq 7pAA== MIME-Version: 1.0 X-Received: by 10.49.74.227 with SMTP id x3mr72540750qev.29.1375130070409; Mon, 29 Jul 2013 13:34:30 -0700 (PDT) Sender: jakub.php@gmail.com Received: by 10.224.178.69 with HTTP; Mon, 29 Jul 2013 13:34:30 -0700 (PDT) In-Reply-To: References: <51F177E7.3020103@sugarcrm.com> <51F182D2.7030007@sugarcrm.com> <1374793278.3605.1436.camel@guybrush> <1374833069.3605.2106.camel@guybrush> <1374838415.3605.2211.camel@guybrush> <1374847163.3605.2377.camel@guybrush> <51F2E393.5090206@nebm.ist.utl.pt> <51F2E53E.1040707@sugarcrm.com> Date: Mon, 29 Jul 2013 21:34:30 +0100 X-Google-Sender-Auth: GhptmtdYXsONhpjjoD0dE0ke9SM Message-ID: To: Michael Wallner Cc: Stas Malyshev , Gustavo Lopes , =?ISO-8859-1?Q?Johannes_Schl=FCter?= , Nikita Popov , PHP internals list , "nikic@php.net" Content-Type: multipart/alternative; boundary=047d7bdc08c25e023904e2ac6b08 Subject: Re: [PHP-DEV] New handler for retrieving properties when object is serialized From: bukka@php.net (Jakub Zelenka) --047d7bdc08c25e023904e2ac6b08 Content-Type: text/plain; charset=ISO-8859-1 Hi What's about unserialization? > Yeah that's actually a good point! :) It could be handled by implicit object unserialization if the unserialize callback is NULL. However this is not optimal for performance and also create properties in the object which doesn't have to be necessary. There should be functions that help with parsing the string buffer that is passed to unserialize class callback. Sort of opposite to API for serialization. It should be part of RFC. I will add it. > Where does the state come from when recursively calling serialize? > I am not sure if I understand the question. The serialize_state will be a sort of wrapper for smart_str with some additions for checking whether the functions are called in correct order. The state instance will be in most cases a local variable (as it is in the example). In case you try to serialize object zval (using php_serailize_property_zval), it would try to serialize the object the same way and the resulted string would be added to the state buffer (will be in RFC...). Did I answer your question? I will try to clarify the RFC a bit. Any feedback would be much appreciated. Thanks. Jakub --047d7bdc08c25e023904e2ac6b08--