Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76158
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.175 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
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 21:55:56 +0200
Message-ID: <CAMUwpuRhHci9-ad1=GgRASDz34xb3oSnV1-ubHDwbu9=M9YrjQ@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Ferenc Kovacs <tyra3l@gmail.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=bcaec529a00774c54704ff1e1697
Subject: Re: [PHP-DEV] Problems with the fix for the BC break introduced in
 5.4.29 and 5.5.13
From: jpauli@php.net (Julien Pauli)

--bcaec529a00774c54704ff1e1697
Content-Type: text/plain; charset=UTF-8

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 fly
> > 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 (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.



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 classes,
for 5.6.0.

A quick word as well to say I'm against giving the opportunity to userland
to remove the final attribute, as this will lead to lots of bugs, some of
them not even fixable I think.


Julien.Pauli

--bcaec529a00774c54704ff1e1697--