Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:75144 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 20847 invoked from network); 30 Jun 2014 15:56:01 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 30 Jun 2014 15:56:01 -0000 Authentication-Results: pb1.pair.com header.from=julienpauli@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=julienpauli@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.182 as permitted sender) X-PHP-List-Original-Sender: julienpauli@gmail.com X-Host-Fingerprint: 209.85.220.182 mail-vc0-f182.google.com Received: from [209.85.220.182] ([209.85.220.182:37742] helo=mail-vc0-f182.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 42/10-19922-09881B35 for ; Mon, 30 Jun 2014 11:56:00 -0400 Received: by mail-vc0-f182.google.com with SMTP id il7so7874049vcb.27 for ; Mon, 30 Jun 2014 08:55:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=StM+a+erpYQY8XtCBClZWE5+TFQY7vafaCSFBNPQxU8=; b=tfliz5Td5aPYSKoK4Si6xPTujC4yY5Jc8OyvlPpH2cRn7G3ADrRhKA31o3H9KWl3BQ L+ExwuXh7wh6HxZXqHG/8AKOOwboaWS3g2CDkqEULGNRYc40Agry+FCHbnBNgxTcbdOS DdxgJJNiWTGioOpppP/hZK+zOv0dk/WTydXVA7NKsNFxIyMIvgd8h6CrizfW5tij3Aer B++/mRrJIa5Wx3HmWY5tK6NsYgX9hZhJheqwZMF1ENsbDoeP3+LhDTu/LawMr05xf9iA +BwfJwBp5TYn7J5lTEJWcTpttNwKepMvGHjy0SIYWvPfUa08Z6gTnr+1dxs2CJ8IX3So Rbcg== X-Received: by 10.52.170.236 with SMTP id ap12mr1005912vdc.79.1404143756491; Mon, 30 Jun 2014 08:55:56 -0700 (PDT) MIME-Version: 1.0 Sender: julienpauli@gmail.com Received: by 10.220.81.68 with HTTP; Mon, 30 Jun 2014 08:55:15 -0700 (PDT) In-Reply-To: References: <53A1C722.9060501@fedoraproject.org> <53A21137.6010705@sugarcrm.com> <53A2A9BD.1070603@sugarcrm.com> <53A3874E.20704@sugarcrm.com> <53A62AFF.4080302@sugarcrm.com> <53B10D59.4060206@sugarcrm.com> Date: Mon, 30 Jun 2014 17:55:15 +0200 X-Google-Sender-Auth: scS215bdo9kVnq2mt48kHey9I4E Message-ID: To: Ferenc Kovacs Cc: Stas Malyshev , Remi Collet , PHP Internals , Sebastian Bergmann , Marco Pivetta Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Re: Problems with the fix for the BC break introduced in 5.4.29 and 5.5.13 From: jpauli@php.net (Julien Pauli) On Mon, Jun 30, 2014 at 11:43 AM, Ferenc Kovacs wrote: > > 2014.06.30. 9:10, "Stas Malyshev" ezt =C3=ADrta: > > >> >> Hi! >> >> > Can anybody suggest a workaround for this problem? >> > Should `ReflectionClass#newInstanceWithoutConstructor()` be enabled fo= r >> > 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 cla= ss >> > 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 (l= azy > 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 t= he > 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 =3D> 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