Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75132
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <53A62AFF.4080302@sugarcrm.com>
References: <CAH-PCH6xEXspisLOHtiTbViA4vDTk7q6LM3t_Bh9Dzr1cj_Nag@mail.gmail.com>
 <53A1C722.9060501@fedoraproject.org> <53A21137.6010705@sugarcrm.com>
 <CAMUwpuT_S2EE6cdJM95RzY4vmORGx3vJ9+gau8G3EZCMsNSydA@mail.gmail.com>
 <53A2A9BD.1070603@sugarcrm.com> <CAH-PCH5-vtCVvGvceMqt6rDXq4zo0Vb34cyDK3KdBUNfg_oLyg@mail.gmail.com>
 <CADyq6sKQbV+Avzfs3OAdGM9Hc85i18t0LSATD6Rk=HjqKOMgBg@mail.gmail.com>
 <53A3874E.20704@sugarcrm.com> <CAH-PCH6nSk0ir_TSjhCd0BVhiY5UsOsLKzqKhqfaU1G0ghi4Tg@mail.gmail.com>
 <53A62AFF.4080302@sugarcrm.com>
Date: Sun, 29 Jun 2014 16:03:07 +0200
Message-ID: <CADyq6s+N_mNc-n1g=S5LwWBZ9fkZ+hqRc3Ycu8M7EBd9Hc1ABw@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Ferenc Kovacs <tyra3l@gmail.com>, Sebastian Bergmann <sebastian@php.net>, Julien Pauli <jpauli@php.net>, 
	Remi Collet <remi@fedoraproject.org>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113a7996b1bea804fcfa010f
Subject: Re: [PHP-DEV] Re: Problems with the fix for the BC break introduced
 in 5.4.29 and 5.5.13
From: ocramius@gmail.com (Marco Pivetta)

--001a113a7996b1bea804fcfa010f
Content-Type: text/plain; charset=UTF-8

Just a follow-up on this: it looks like the most common use-cases affected
by the breakage are about classes extending `ArrayObject`, which is
reasonable.

Creating a new instance without invoking their constructor is now not
possible in 5.4.30, 5.5.14 and 5.6.0-rc.1 because of the "invalid
serialization format" error.
The only workaround I found is creating a new class at runtime, overriding
the constructor and instantiating it, which has the horrible side-effect of
`get_class()` obviously returning something different from expectations,
and is going to break other things in codebases that highly rely on
reflection.

Can anybody suggest a workaround for this problem?
Should `ReflectionClass#newInstanceWithoutConstructor()` be enabled for
those classes?
If so, in 5.4/5.5?

Is this just a dead end and are we supposed to just disallow mocking on
those particular classes?

My other solution would be to build a map (case-by-case) of internal PHP
classes and custom ways of instantiating/serializing them.
Something like following example, which is horror: http://3v4l.org/oSPvF

An additional problem is when a userland class extends an internal class
AND implements the `Serializable` interface on its own.
In such cases, knowing the serialization format is impossible for us, and
`ReflectionClass#newInstanceWithoutConstructor()` still cannot be used.

Any direction here would be useful. I'm considering going down the
"exception thrown" way, as suggested by Ferenc, but for 50600 it would be
neat to just have `ReflectionClass` doing the trick.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

--001a113a7996b1bea804fcfa010f--