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

Hi! > Can anybody suggest a workaround for this problem? > Should ReflectionClass#newInstanceWithoutConstructor() be > enabled for > those classes? > If so, in 5.4/5.5? I think we should move away from the practice of using serializer for something it was never made for, namely a weird way of instantiating classes. Serializer should be working only with serialized data. Now, the question is can we instantiate the internal class without calling its ctor, and the answer here would probably be "no", at least not safely. While in the case of user class the engine can be reasonable sure even if you don't call the ctor the basic structures are initialized properly, in the case of the internal class all bets are off. I'm not sure yet which use cases require ctor not to be called, but I'm not sure how we can deliver on internal classes here. > 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. Again, I would like to strongly suggest not using serialization format for hacks. It's just not what it's for, and we already suffering the consequences. We need some other solution here. Let's start with this: what gives us the guarantee that internal class which is extended by userland class will be found in proper state without calling the ctor? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/