Re: Problems with the fix for the BC break introduced in 5.4.29 and 5.5.13
| From: | Ferenc Kovacs | 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