Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:75137 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 85542 invoked from network); 30 Jun 2014 07:10:22 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 30 Jun 2014 07:10:22 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.123 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.123 smtp123.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.123] ([108.166.43.123:44442] helo=smtp123.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id FB/11-07865-D5D01B35 for ; Mon, 30 Jun 2014 03:10:21 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp16.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id C5A643810BD; Mon, 30 Jun 2014 03:10:18 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp16.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 1C2F73808A5; Mon, 30 Jun 2014 03:10:18 -0400 (EDT) Message-ID: <53B10D59.4060206@sugarcrm.com> Date: Mon, 30 Jun 2014 00:10:17 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Marco Pivetta CC: Ferenc Kovacs , Sebastian Bergmann , Julien Pauli , Remi Collet , PHP Internals References: <53A1C722.9060501@fedoraproject.org> <53A21137.6010705@sugarcrm.com> <53A2A9BD.1070603@sugarcrm.com> <53A3874E.20704@sugarcrm.com> <53A62AFF.4080302@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: Problems with the fix for the BC break introduced in 5.4.29 and 5.5.13 From: smalyshev@sugarcrm.com (Stas Malyshev) 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/