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

From: 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:
Perhaps anonymous classes ?
yeah, that is one of the proposed solution.
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?
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)
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)

« previous php.internals (#75147) next »