Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75145
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAMUwpuSKyWjZA9t2JhFhtCry69qEbd8GLN-hyMnHULtGCtB37w@mail.gmail.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>
	<CAH-PCH6uKYNnqVWvQrvtGxQAzxQK+jUA8yqHfWP0e_p+XuFMMQ@mail.gmail.com>
	<CAMUwpuSKyWjZA9t2JhFhtCry69qEbd8GLN-hyMnHULtGCtB37w@mail.gmail.com>
Date: Mon, 30 Jun 2014 18:10:52 +0200
Message-ID: <CAH-PCH6B2Okicap0js8TdJ9jv_HQnpL0D4OUyU4uvxn0a6Ysiw@mail.gmail.com>
To: Julien Pauli <jpauli@php.net>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, 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=001a113a6a9a41377104fd0fe718
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)

--001a113a6a9a41377104fd0fe718
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 30, 2014 at 5:55 PM, Julien Pauli <jpauli@php.net> wrote:

> 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 =C3=ADrt=
a:
> >
> >
> >>
> >> 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 reasonab=
le
> >> 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, b=
ut
> >> 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 b=
e
> >> > 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 =3D> you can't have an object without
> calling its constructor.
>

currently it is allowed to extend the class and override the __construct()
to not call the parents.


> 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.
>

more than that, Internal classes can initialize and depend on properties
that you can't reproduce from an userland method (without calling the
original __construct()).


>
> Lazy init also is not a viable option , we can't put INIT_CHECK()
> macros everywhere.
>

and some of those macros would do what __construct() would do anyways, so
if you are instantiating without a constructor so that there is no code
execution, you wouldn't want lazy init also.


>
> Perhaps anonymous classes ?
>

yeah, that is one of the proposed solution.


> Or just to know , why can't you create a class that extends the one
> you want, and write an empty constructor into it ?
>

some mocking frameworks uses that concept for instanitating objects:
http://news.php.net/php.internals/75125


> 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 ?
>
>
but this will still produce incomplete/unstable objects which are exposed
to the dos/security problems.
so I think that supporting the creation of mocks/doubles natively(through
Reflection)

I think it would make sense to create a wiki page (rfc maybe) and summarize
the topic, because I got the feeling that there are some ideas/suggestions
which are brought up multiple times as if they were not mentioned before. I
will try to write this up today or tomorrow and then send a mail about it
so you guys can review and extend on it.


--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--001a113a6a9a41377104fd0fe718--