Re: Re: Problems with the fix for the BC break introduced in 5.4.29 and 5.5.13
| From: | Nikita Nefedov | Date: | Mon, 30 Jun 2014 16:42:57 +0000 |
| Subject: | Re: 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 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-75147@lists.php.net to get a copy of this message | ||
On Mon, 30 Jun 2014 20:10:52 +0400, Ferenc Kovacs <tyra3l@gmail.com> wrote:
I can't really understand how would they help with the internal classes? Would they call constructor or not? If not - the problem is still there isn't it?Perhaps anonymous classes ?yeah, that is one of the proposed solution.
Natively. But again, how can we do this generically? I mean not touching definition of the classes itself. You will still need to instantiate an object with the internal class entry, or am I wrong here? If it comes only to the problem of mocking the solution could also be to allow usage of classes as an interfaces. So for example if we will be able to write something like this: class MockedSplFileInfo implements \SplFileInfo { public function getBaseName(){ /* some mocking logic */ } ... and so on ... } I don't see any way to keep the ability to instantiate internal class without constructor *and* to guarantee its stability at the same time. The only way is to not instantiate it. (assuming we don't ask classes to make init checks on every possible call)That way you'd be able to create an object using "new" , and redefine the methods you want to make them return what you want. am I wrong ?but this will still produce incomplete/unstable objects which are exposed to the dos/security problems. so I think that supporting the creation of mocks/doubles natively(through Reflection)