Re: An BC issue in unserialize

On Thu, Jul 17, 2014 at 9:58 AM, Stas Malyshev <smalyshev@sugarcrm.com> wrote: > Hi! > > > As discussed in previous threads about this failure, we (doctrine) can > > move away from the unserialize() hack if > > ReflectionClass#newInstanceWithoutConstructor() provides > > support for > > internal classes. > > Could you explain why it is needed to instantiate internal classes > without calling the ctor? I'd like to understand the use case more. > I honestly don't have a use-case for it myself, and I also strongly disagree with extending internal PHP classes due to their fragility. What I know is that many Doctrine users extend ArrayObject in entities, which is what caused us to apply a hotfix only for 5.4.29 and 5.5.13, and NOT 5.6.0. > > It doesn't need to cover ALL internal classes, just the most commonly > > extended ones. > > The problem is we do not know which of these classes may fail if > instantiated without initializing. With PHP classes, it's easy since the > engine takes care of the basic plumbing. With C classes, if you don't > call the function, you get nulls or worse, garbage, in places where > values are expected. Yes, that indeed. What I am suggesting is to provide a small map of internal PHP classes that are supported by ReflectionClass#newInstanceWithoutConstructor(), so that their internal data can be initialized even if the userland constructor is not invoked. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/