Re: Re: Problems with the fix for the BC break introduced in 5.4.29 and 5.5.13

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/