Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75139
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <53B10D59.4060206@sugarcrm.com>
References: <CAH-PCH6xEXspisLOHtiTbViA4vDTk7q6LM3t_Bh9Dzr1cj_Nag@mail.gmail.com>
	<53A1C722.9060501@fedoraproject.org>
	<53A21137.6010705@sugarcrm.com>
	<CAMUwpuT_S2EE6cdJM95RzY4vmORGx3vJ9+gau8G3EZCMsNSydA@mail.gmail.com>
	<53A2A9BD.1070603@sugarcrm.com>
	<CAH-PCH5-vtCVvGvceMqt6rDXq4zo0Vb34cyDK3KdBUNfg_oLyg@mail.gmail.com>
	<CADyq6sKQbV+Avzfs3OAdGM9Hc85i18t0LSATD6Rk=HjqKOMgBg@mail.gmail.com>
	<53A3874E.20704@sugarcrm.com>
	<CAH-PCH6nSk0ir_TSjhCd0BVhiY5UsOsLKzqKhqfaU1G0ghi4Tg@mail.gmail.com>
	<53A62AFF.4080302@sugarcrm.com>
	<CADyq6s+N_mNc-n1g=S5LwWBZ9fkZ+hqRc3Ycu8M7EBd9Hc1ABw@mail.gmail.com>
	<53B10D59.4060206@sugarcrm.com>
Date: Mon, 30 Jun 2014 11:43:09 +0200
Message-ID: <CAH-PCH6uKYNnqVWvQrvtGxQAzxQK+jUA8yqHfWP0e_p+XuFMMQ@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Julien Pauli <jpauli@php.net>, Remi Collet <remi@fedoraproject.org>, 
	PHP Internals <internals@lists.php.net>, Sebastian Bergmann <sebastian@php.net>, 
	Marco Pivetta <ocramius@gmail.com>
Content-Type: multipart/alternative; boundary=001a1134f152a7264104fd0a7c71
Subject: Re: [PHP-DEV] Re: Problems with the fix for the BC break introduced
 in 5.4.29 and 5.5.13
From: tyra3l@gmail.com (Ferenc Kovacs)

--001a1134f152a7264104fd0a7c71
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2014.06.30. 9:10, "Stas Malyshev" <smalyshev@sugarcrm.com> ezt =C3=ADrta:
>
> 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 clas=
s
> > 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.

--001a1134f152a7264104fd0a7c71--