Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77562
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54220A65.7080303@sugarcrm.com>
References: <CAPRqa+GgN6n9nmEUdaP1VxxFddQRwE1QDbxXqT082v3Qy8DzdQ@mail.gmail.com>
	<CAKxcST8D0QscwN2W3KuvOkousqOfB=rBAVUkWJt3BGJ6vCH2Ug@mail.gmail.com>
	<CAPRqa+Ebp+HFJu0nnok4Z=6fvexCyz5pLv5uUc-5syE=a_H6+g@mail.gmail.com>
	<CAKxcST_PckLRmkYUwog=wC4K=Of3tR5cZeYv47e1HZ71C4VBxA@mail.gmail.com>
	<CAPwsocEO3YgWU6dPKa8-g-VQaOqtKmpAH79icVgn4X6w7sVeYQ@mail.gmail.com>
	<CAEZPtU4EK_SE7Q+45Wo=r=Rvt_MFyL9A7ZL35mie8L11-oUgcw@mail.gmail.com>
	<CAKxcST_UgUCMBQt42VZEFwgvPvaaXT3it8YgMytEwKtDX1gDFA@mail.gmail.com>
	<5421EB4A.4000101@sugarcrm.com>
	<CAPRqa+ESx9+N5wHEhrZ-1pPQ-Qa8-RfAidqhRR1k2pw9bwucgA@mail.gmail.com>
	<54220A65.7080303@sugarcrm.com>
Date: Wed, 24 Sep 2014 03:39:26 +0300
Message-ID: <CAPRqa+GL-OLSLQ6ZPW92HPkLd=DVVkCUz0FgybwvEfcxxc==6g@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Paul Dragoonis <dragoonis@gmail.com>, Pierre Joye <pierre.php@gmail.com>, Leigh <leight@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Improve PHP 7 serialization
From: park.framework@gmail.com (Park Framework)

I agree, you're right.

My desire to override the existing algorithm serialize(), due to the
need to change the method serialization, but does not change the
source code (legacy code, ext PHP)

2014-09-24 3:03 GMT+03:00 Stas Malyshev <smalyshev@sugarcrm.com>:
> Hi!
>
>> Perhaps a compromise would be to choose the quickest method of
>> serialization, add it to PHP core.
>>
>> In php.ini add the directive
>> serialization.method = msgpack / Igbinary / ....
>
> We could, but what if you need to read/write data specifically from
> current PHP serializer? You'd have to mess then with runtime directives,
> it doesn't look like a good design. That's like having one db_query()
> function for all databases and have a config parameter that switches the
> global database type. I think the other option is better - to have
> extensions for all underlying functions and abstraction layer (PDO or
> userspace) that provides unified API if needed.
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/