Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68325
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain nebm.ist.utl.pt from 193.136.128.22 cause and error)
Message-ID: <51F2E393.5090206@nebm.ist.utl.pt>
Date: Fri, 26 Jul 2013 23:01:07 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:22.0) Gecko/20100101 Thunderbird/22.0
MIME-Version: 1.0
To: =?UTF-8?B?Sm9oYW5uZXMgU2NobMO8dGVy?= <johannes@schlueters.de>, 
 Jakub Zelenka <bukka@php.net>
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>
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>
In-Reply-To: <1374847163.3605.2377.camel@guybrush>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] New handler for retrieving properties when object is
 serialized
From: glopes@nebm.ist.utl.pt (Gustavo Lopes)

On 26-07-2013 15:59, Johannes Schlüter 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)

This is a gross misrepresentation. The vast majority of extensions will 
not care about this purpose, just like most extensions do not care about 
get_debug_info or get_gc or about the purpose in read_property. If a new 
purpose is added, this would not be any different than adding a new hook 
as long as:

1) the extension doesn't purposefully break forward compatibility, for 
example by doing switch(purpose) { ... default: panic(); } and
2) the new hook would default to get_properties, either by explicitly 
setting the pointer to get_properties in the standard handlers array or 
by having the engine fall back to get_properties (the last one was the 
solution adopted for get_debug_info and get_gc afaik).

Yes, this would break extensions. But we never made any promises about 
source BC for extensions. In fact, we actually break it for every 
release, sometimes in rather subtle ways like in 5.4 (due to interned 
strings, and object properties storage).


> 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.
>

Alternatively, could the problem perhaps be mitigated by making 
available some utility functions for serializing native types?

-- 
Gustavo Lopes