Re: Problems with the fix for the BC break introduced in 5.4.29 and 5.5.13

From: Date: Sat, 26 Jul 2014 20:19:55 +0000
Subject: Re: Problems with the fix for the BC break introduced in 5.4.29 and 5.5.13
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18  Groups: php.internals 
Request: Send a blank email to internals+get-76159@lists.php.net to get a copy of this message
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 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. > that would be nice. > > 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. > 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. -- Ferenc Kovács @Tyr43l - http://tyrael.hu

« previous php.internals (#76159) next »