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

2014.06.30. 9:10, "Stas Malyshev" <smalyshev@sugarcrm.com> ezt írta: > > 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? currently nothing. we could 1, make sure that every internal class is fine without the constructor (lazy initiation for example). this would be probably the most work. 2, we could make it mandatory or allow internal classes to opt-in to mandatory that the base constructor is always called. 3, we could turn the mandatory contructors final. 1, would allow us to keep instantiating the internal classes without constructors, but it would be error prune imo. 2/3 would could defend against the segfaults/etc but would be a pita to the userland. I think that the mid/long range solution should be to provide a way to dynamically create objects which doesn't inherit code from the original class/interface but the signature should be compatible (Sebastian opened a separate thread about using anonymous classes for this.), but I don't think we have time for that in 5.6. But we should provide an upgrade path, so the current status in 5.6 is a no-go imo.