Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:68322 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 26246 invoked from network); 26 Jul 2013 13:59:46 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Jul 2013 13:59:46 -0000 Authentication-Results: pb1.pair.com header.from=johannes@schlueters.de; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=johannes@schlueters.de; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.211.66 cause and error) X-PHP-List-Original-Sender: johannes@schlueters.de X-Host-Fingerprint: 217.114.211.66 config.schlueters.de Received: from [217.114.211.66] ([217.114.211.66:62115] helo=config.schlueters.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A4/F5-25917-1D082F15 for ; Fri, 26 Jul 2013 09:59:46 -0400 Received: from [192.168.2.20] (ppp-93-104-4-146.dynamic.mnet-online.de [93.104.4.146]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by config.schlueters.de (Postfix) with ESMTPSA id 3D13965FC8; Fri, 26 Jul 2013 15:59:42 +0200 (CEST) To: Jakub Zelenka Cc: Stas Malyshev , Nikita Popov , PHP internals list , "nikic@php.net" 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> Content-Type: text/plain; charset="UTF-8" Date: Fri, 26 Jul 2013 15:59:23 +0200 Message-ID: <1374847163.3605.2377.camel@guybrush> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] New handler for retrieving properties when object is serialized From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=) On Fri, 2013-07-26 at 14:14 +0100, Jakub Zelenka wrote: > > > > > > This means one has to touch every extension using those hooks. "more use > > cases in the future" means having to do this over and over again, for a > > feature I see little benefit in. > > > > I don't want to change get_properties. That would break too many > extensions. The idea is to create something like > > HashTable *get_special_properties(zval *object, int purpose, int *is_tmp > TSRMLS_DC) > > This would replace get_debug_info so the number of hooks would stay the > same. > The only extensions that would need to be changed are the ones that use > get_debug_info. The purposes could be debug, serialize, array_casting. If > there is a new use case, you would just add new purpose and wouldn't have to change > anything. Such a way for overloading is bad. This is painful on each update. If there are different things to do use different hooks. The implementations might call the same implementation but a "purpose" option leads to a long term maintenance hell whenever there is a change.(a tiny bit better would be using an enum instead of int as in some situations compilers/analyzers might give a hint ... but still a mess) But I still don't buy the argument for this hook. Typically internal classes use some C data structure for keeping their internal state. Often actually in a form that it can not be represented in zval. From that observation (after a few years of looking at phpsrc, pecl external and close-source exts) Serializable is the preferred way to serialize these in an efficient way (converting everything in zvals, then serialize, finally freeing temporary data is a quite expensive way ..) (mind: comparison with debug hooks is only of limited use. a) a debug feature has less performance relevance b) a debug feature doesn't need to convert the full state and has no need to be reversible) So what is being proposed is to extend our already too large API with yet another way of doing something for edge cases for which we have a good solution for the general case already. > > I haven't looked deeper but isn't your whole point to change the > > serialized representation of the object, to include all data "properly"? > > > > > No the whole point was returning the same properties but only if the object > is serialized or debugged. Deeper explanation is in this thread: So the purpose is to have a different serialized representation, so there would be compatibility issues, similar to going to Serializable. johannes