Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68323
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.53 as permitted sender)
MIME-Version: 1.0
Sender: jakub.php@gmail.com
In-Reply-To: <1374847163.3605.2377.camel@guybrush>
References: <CAEKnhAGd=Opdsc88Z0LD8e_fwtoUQe2wpZCYh8VtiwFLOA09NQ@mail.gmail.com>
	<51F177E7.3020103@sugarcrm.com>
	<CAF+90c89OsTJJ6x5MjtmV-e9uEcuL38qnaU63Ep5eNrj0C1HKw@mail.gmail.com>
	<51F182D2.7030007@sugarcrm.com>
	<CAEKnhAFT4VqATgkbbRMAiYb46FKDt--nLacySia6kXo9FxEBog@mail.gmail.com>
	<1374793278.3605.1436.camel@guybrush>
	<CAEKnhAE1vHEx9CexODpgamhew2qCj2r9YU_Ytv+6v=GYOafJQg@mail.gmail.com>
	<1374833069.3605.2106.camel@guybrush>
	<CAEKnhAGbbBhmeyZcB28rsfpx1ZxbaSuHiFNzWs5BVZHqNifd=w@mail.gmail.com>
	<1374838415.3605.2211.camel@guybrush>
	<CAEKnhAHbYocBtduSuyx3CT--6-2pV_4VXJZHnaeaBK423B-4xg@mail.gmail.com>
	<1374847163.3605.2377.camel@guybrush>
Date: Fri, 26 Jul 2013 16:18:50 +0100
Message-ID: <CAEKnhAGCybfYiQZiY=Uh7EKc73McbMnAd0U+Nf=9kdLi+1nVqQ@mail.gmail.com>
To: =?ISO-8859-1?Q?Johannes_Schl=FCter?= <johannes@schlueters.de>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, Nikita Popov <nikita.ppv@gmail.com>, 
	PHP internals list <internals@lists.php.net>, "nikic@php.net" <nikic@php.net>
Content-Type: multipart/alternative; boundary=047d7bdc8e1ceb1d5d04e26ba8f1
Subject: Re: [PHP-DEV] New handler for retrieving properties when object is serialized
From: bukka@php.net (Jakub Zelenka)

--047d7bdc8e1ceb1d5d04e26ba8f1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Jul 26, 2013 at 2:59 PM, Johannes Schl=FCter
<johannes@schlueters.de>wrote:

>
> 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)
>
>
Ok so probably better not to do that :)


> 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 ..)
>

I agree that Serializable is better for performance. The reason why
I proposed this is to differentiate serialization properties from normal
properties in cases where Serializable would require lots
of coding for a small benefit (object is not serialized often)
or it is not an options (DateTime - see bellow).


>
> So the purpose is to have a different serialized representation, so
> there would be compatibility issues, similar to going to Serializable.
>
>
Yeah but that serialized representation is exactly the same as
the current representation (the serialized strings before the patch is
exactly the same as the string after the patch :)).  The difference is that
get_properties returns empty HashTable now. The serialization is
backward compatible though.

I just want to find a solution for this problem. What would you do?
Would you use Serialazable even if it breaks apps after updating PHP.
Or would you still use get_properties (possibly with testing
serialize_lock) ?

Jakub

--047d7bdc8e1ceb1d5d04e26ba8f1--