On Thu, Jul 17, 2014 at 9:58 AM, Stas Malyshev <smalys...@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/
