Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76159
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAMUwpuRhHci9-ad1=GgRASDz34xb3oSnV1-ubHDwbu9=M9YrjQ@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>
	<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>
	<CAMUwpuRhHci9-ad1=GgRASDz34xb3oSnV1-ubHDwbu9=M9YrjQ@mail.gmail.com>
Date: Sat, 26 Jul 2014 22:19:55 +0200
Message-ID: <CAH-PCH4uoioA0p-q6RrCuO8SL8QVgKi-Jx12rZ5wHWiHrzNxEw@mail.gmail.com>
To: Julien Pauli <jpauli@php.net>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, Alexey Zakhlestin <indeyets@gmail.com>, 
	Marco Pivetta <ocramius@gmail.com>, Sebastian Bergmann <sebastian@php.net>, 
	Remi Collet <remi@fedoraproject.org>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c2e0a8ce9c5704ff1e6968
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)

--001a11c2e0a8ce9c5704ff1e6968
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Jul 26, 2014 at 9:55 PM, Julien Pauli <jpauli@php.net> wrote:

> 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 f=
ly
>> > 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
>> they?
>>
>> > 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.
>>
>> > a nice thing from OOP POV and also will cause problems if/when we
>> > introduce a reflection method removing final from classes/methods (thi=
s
>> > 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.
>
>
>
> Like I said in a previous mail, only Dom, Mysqli and sqlite3 need patch
> to be able to work with only create_object invoked.
> I'm not sure about COM as I can't setup a test environment for it.
>
> I recently started patching mysqli.
> I think it is feasable to have all of them patched so that
> newInstanceWithoutConstructor() may be safely "opened" to internal classe=
s,
> for 5.6.0.
>

that would be nice.


>
> A quick word as well to say I'm against giving the opportunity to userlan=
d
> to remove the final attribute, as this will lead to lots of bugs, some of
> them not even fixable I think.
>

just to clarify: I didn't suggested to introduce this method (it was
proposed by somebody else in the past), just mentioned that I don't think
that turning classes/constructors into final only to be safe from these
kind of problems is a bad idea imo, and one of my arguments was that there
is a chance that we would like to allow userland to override final, and it
would cause problems anyways.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--001a11c2e0a8ce9c5704ff1e6968--