Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76161
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <53D2E7A2.9010209@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>
	<F5324819-A85F-47BA-8FE5-27FBE87E1B89@gmail.com>
	<CAH-PCH6Tb-QbTaB3_qthpiGo4fcs0afViDhACmcur=vZ+=HnFg@mail.gmail.com>
	<53D2DA3B.9020308@sugarcrm.com>
	<CAH-PCH6OKgEK8VAehHuW8Eq5-Hx1LsdwowT6JnvFxznr7DNc3g@mail.gmail.com>
	<53D2E7A2.9010209@sugarcrm.com>
Date: Sat, 26 Jul 2014 22:58:16 +0200
Message-ID: <CAH-PCH4L8X7Fu9LmAK5OPs7Sx7RXLqO+CfDPfU8XiuH7jvkoRw@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Alexey Zakhlestin <indeyets@gmail.com>, Marco Pivetta <ocramius@gmail.com>, 
	Sebastian Bergmann <sebastian@php.net>, Julien Pauli <jpauli@php.net>, Remi Collet <remi@fedoraproject.org>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113abd54e816cc04ff1ef253
Subject: Re: [PHP-DEV] Problems with the fix for the BC break introduced in
 5.4.29 and 5.5.13
From: tyra3l@gmail.com (Ferenc Kovacs)

--001a113abd54e816cc04ff1ef253
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Jul 26, 2014 at 1:26 AM, Stas Malyshev <smalyshev@sugarcrm.com>
wrote:

> Hi!
>
> > yeah, that would work ofc, but as these libs seems to have instanitate
> > arbitrary classes, that would require either generating files on the fl=
y
> > and including them or simply evaling them, but of those are a  bit
> > dirtier than using Reflection for the same job.
>
> True but that's what phpunit, etc. are doing for mocks anyway, aren't the=
y?


nope, some mock frameworks do that (afair atoum for example) but
phpunit(phpunit-mock-objects to be more precise) was using the serialize
trick and newInstanceWithoutConstructor() (
https://github.com/sebastianbergmann/phpunit-mock-objects/blob/42f29d650744=
fd7ce785e7a4dd3598a09b0bfd2b/src/Framework/MockObject/Generator.php#L273),
and now they switched to Instantiator from Ocramius(he also participated in
this thread) which also uses the unserialize trick and
newInstanceWithoutConstructor() (
https://github.com/Ocramius/Instantiator/blob/86e562799ceb87316fcb70e151551=
f47dd215a0f/src/Instantiator/Instantiator.php#L80
).


>


> > true, but it can also be used to argue for loosening the restriction,
> > why restrict something from Reflection, which is already possible from
> > simple class extension.
>
> I agree, probably makes sense to allow it if you can do it anyway.
> Reflection is not something you can trigger without explicit codding
> (unlike O: thing) so it's fine with me.
>

yeah, exactly.


>
> > a nice thing from OOP POV and also will cause problems if/when we
> > introduce a reflection method removing final from classes/methods (this
> > was already proposed not that long ago with a working patch but was
> > turned down because other reasons).
>
> That probably wouldn't be a good idea, especially for internal classes.
>

I should have left out this argument, because that has it's own can of
worms, but if anybody interested in the original proposal:
http://grokbase.com/t/php/php-internals/121gmxkz1c/php-dev-reflection-to-re=
move-final
I wasn't proposing merging this in my mail, just argued that if this
proposal ever merged, that would either require fixing up the finals
anyways or it would be possible to trigger similar segfaults and stuff.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--001a113abd54e816cc04ff1ef253--