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

On Mon, Jun 30, 2014 at 11:43 AM, Ferenc Kovacs <tyra3l@gmail.com> wrote: > > 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. I agree that the problem seem to have no solution. An object has a constructor => you can't have an object without calling its constructor. Passing the theoretical concepts, Stas just proved that the practical are just right : we can't assume internal class will work without calling their constructor as they usually initialize internal structures and states. Lazy init also is not a viable option , we can't put INIT_CHECK() macros everywhere. Perhaps anonymous classes ? Or just to know , why can't you create a class that extends the one you want, and write an empty constructor into it ? That way you'd be able to create an object using "new" , and redefine the methods you want to make them return what you want. am I wrong ? Julien