Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76433
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.42 as permitted sender)
MIME-Version: 1.0
Sender: are.you.winning@gmail.com
In-Reply-To: <CAMUwpuRDxZ0AQxwc8DPE190K+XMpgnRKJyVVmfJEj-LiOywXBg@mail.gmail.com>
References: <CAM+1YOz8bXZDoihBkRZPK2kKjMZN6cTxCWx+pSyCK2oUqPVaMA@mail.gmail.com>
	<CAH-PCH70+OYhvCkNwV92Zbz3sSHK7ck7jQkJwRdR9vBjwY9zsw@mail.gmail.com>
	<CAMUwpuRDxZ0AQxwc8DPE190K+XMpgnRKJyVVmfJEj-LiOywXBg@mail.gmail.com>
Date: Mon, 11 Aug 2014 17:44:14 +0100
Message-ID: <CAGAGxbaB-C17LEbta92G2v2OS_Y=77p0z+2KetBTojXVi66DMg@mail.gmail.com>
To: Julien Pauli <jpauli@php.net>
Cc: Ferenc Kovacs <tyra3l@gmail.com>, Tom Oram <tom@scl.co.uk>, 
	PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Reflection to remove final
From: cw@daverandom.com (Chris Wright)

On 11 August 2014 17:09, Julien Pauli <jpauli@php.net> wrote:
> On Mon, Aug 11, 2014 at 12:59 PM, Ferenc Kovacs <tyra3l@gmail.com> wrote:
>> On Sat, Aug 9, 2014 at 12:35 PM, Tom Oram <tom@scl.co.uk> wrote:
>>
>>> I've just been looking back at the history of this previous conversation...
>>>
>>> http://marc.info/?l=php-internals&m=132673741606531&w=2
>>>
>>> as a mockist tester I'd really REALLY like to see this be possible but I
>>> can see the problem with the original patch modifying the actual existing
>>> class.
>>>
>>> One solution I propose is rather than modify it would it be possible for
>>> the reflection class to be able to duplicate the class with the finals
>>> removed so something like this could be possible:
>>>
>>> final class A
>>> {
>>> }
>>>
>>> $r = new ReflectionClass('A');
>>>
>>> $r->defineExtendableClass('ExtendableA');
>>>
>>> class MockA extends ExtendabledA
>>> {
>>> }
>>>
>>> I'm unfamiliar with the PHP codebase so I thought I'd just ask here to find
>>> out if it sounds possible before diving into the code
>>>
>>> Thoughts?
>>>
>>> Regards,
>>> Tom
>
>
> Supporting this at an engine level would be harder than you think.
>
> We already had lots of difficulties patching
> newInstanceWithoutConstructor() to support internal classes (5.6)
> because they've never been designed to support creation without the
> call to their constructor.
>
> Removing (or giving a way to remove) FINAL should be OK for userland
> classes, but that will be hard to support for internal classes and
> would require lots of work. Some of them could even never support it.

I don't think that it even makes sense to have this as a possibility
for internal classes. tbh I doubt it makes sense to do it in userland
either (class shouldn't have been declared final in the first place)
but there may some testing applications that are not immediately
apparent to me, as implied by the code sample in the original mail.

If such a feature were to be implemented as part of reflection as
suggested (I'm not a fan), not supporting internal classes would be
totally acceptable IMO.