ReflectionClass::newInstanceWithoutConstructor()

13 years ago by Pierre Joye — view source

unread

hi,

I have attached a patch to https://bugs.php.net/bug.php?id=55490 that
implements ReflectionClass::newInstanceWithoutConstructor() to create an
object a class without invoking the constructor.

As there are certain internal classes that would "crash" when their
constructor is not invoked, this new method of the Reflection API only
works for userland-defined classes.

Looks good and as you do the check to avoid internal classes, that's all good :)

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

13 years ago by Gustavo Lopes — view source

unread

On Thu, 25 Aug 2011 10:46:21 +0100, Sebastian Bergmann sebastian@php.net
wrote:

I have attached a patch to https://bugs.php.net/bug.php?id=55490 that
implements ReflectionClass::newInstanceWithoutConstructor() to create
an
object a class without invoking the constructor.

As there are certain internal classes that would "crash" when their
constructor is not invoked, this new method of the Reflection API only
works for userland-defined classes.

What about userland classes that extend internal classes?

--
Gustavo Lopes

13 years ago by Sebastian Bergmann — view source

unread

What about userland classes that extend internal classes?

Good point. How would I implement such a check?

--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/

13 years ago by Kalle Sommer Nielsen — view source

unread

Hi

2011/8/25 Sebastian Bergmann sebastian@php.net:

Good point. How would I implement such a check?

Speaking of which, wouldn't it be easier to check all our internal
classes for such failures and fix them accordingly with this addition
(Fix the dont-crash-without-calling-constructor)?

We could do like that of above and cast an exception instead of
E_RECOVERABLE_ERROR (as I believe is being cast now) in 5.4.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

13 years ago by Sebastian Bergmann — view source

unread

Speaking of which, wouldn't it be easier to check all our internal
classes for such failures and fix them accordingly with this addition
(Fix the dont-crash-without-calling-constructor)?

We could do like that of above and cast an exception instead of
E_RECOVERABLE_ERROR (as I believe is being cast now) in 5.4.

Makes sense to me.

--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/

13 years ago by Etienne Kneuss — view source

unread

Hi,

Speaking of which, wouldn't it be easier to check all our internal
classes for such failures and fix them accordingly with this addition
(Fix the dont-crash-without-calling-constructor)?

We could do like that of above and cast an exception instead of
E_RECOVERABLE_ERROR (as I believe is being cast now) in 5.4.

Makes sense to me.

There is already some standardized checks for 5.4 that wrap around the
get_constructor handler. But it should/could be standardized at the
engine level. And those raise exceptions in case they detect a
uncalled constructor.

--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/

--

--
Etienne Kneuss
http://www.colder.ch

13 years ago by Etienne Kneuss — view source

unread

Hi,

Speaking of which, wouldn't it be easier to check all our internal
classes for such failures and fix them accordingly with this addition
(Fix the dont-crash-without-calling-constructor)?

We could do like that of above and cast an exception instead of
E_RECOVERABLE_ERROR (as I believe is being cast now) in 5.4.

Makes sense to me.

There is already some standardized checks for 5.4 that wrap around the
get_constructor handler.

In SPL, that is

But it should/could be standardized at the
engine level. And those raise exceptions in case they detect a
uncalled constructor.

--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/

--

--
Etienne Kneuss
http://www.colder.ch

--
Etienne Kneuss
http://www.colder.ch

13 years ago by Pierre Joye — view source

unread

What about userland classes that extend internal classes?

Good point. How would I implement such a check?

Checking the same thing than what instanceof does

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

13 years ago by Gustavo Lopes — view source

unread

On Thu, 25 Aug 2011 13:41:27 +0100, Sebastian Bergmann sebastian@php.net
wrote:

What about userland classes that extend internal classes?

Good point. How would I implement such a check?

You could fetch the parent and do the same check, and so on. I think you
might be able to just check whether ce.create_object is not NULL, because
if the internal class doesn't replace create_object, there's no chance of
that class of crashes occurring; plus, they're propagated to the
subclasses.

--
Gustavo Lopes

13 years ago by Sebastian Bergmann — view source

unread

You could fetch the parent and do the same check, and so on. I think you
might be able to just check whether ce.create_object is not NULL, because
if the internal class doesn't replace create_object, there's no chance of
that class of crashes occurring; plus, they're propagated to the subclasses.

I updated the patch accordingly. Thanks!

--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/

13 years ago by Benjamin Eberlei — view source

unread

Thanks for working on this Sebastian, its really appreciated! +1 from me!

On Thu, Aug 25, 2011 at 3:27 PM, Sebastian Bergmann sebastian@php.netwrote:

You could fetch the parent and do the same check, and so on. I think you
might be able to just check whether ce.create_object is not NULL, because
if the internal class doesn't replace create_object, there's no chance of
that class of crashes occurring; plus, they're propagated to the
subclasses.

I updated the patch accordingly. Thanks!

--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/

13 years ago by guilhermeblanco@gmail.com — view source

unread

Sebastian,

This is a hidden gem for us! =D
Thanks a lot for putting your effort into this.

Cheers,

Thanks for working on this Sebastian, its really appreciated! +1 from me!

On Thu, Aug 25, 2011 at 3:27 PM, Sebastian Bergmann sebastian@php.netwrote:

You could fetch the parent and do the same check, and so on. I think you
might be able to just check whether ce.create_object is not NULL, because
if the internal class doesn't replace create_object, there's no chance of
that class of crashes occurring; plus, they're propagated to the
subclasses.

I updated the patch accordingly. Thanks!

--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/

--

--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil

13 years ago by Patrick ALLAERT — view source

unread

2011/8/25 Gustavo Lopes glopes@nebm.ist.utl.pt:

You could fetch the parent and do the same check, and so on.

Checking only the topmost should be enough if traversing the whole
inheritance could be avoided.

I think you
might be able to just check whether ce.create_object is not NULL, because if
the internal class doesn't replace create_object, there's no chance of that
class of crashes occurring; plus, they're propagated to the subclasses.

--
Gustavo Lopes

13 years ago by Patrick ALLAERT — view source

unread

2011/8/25 Patrick ALLAERT patrickallaert@php.net:

2011/8/25 Gustavo Lopes glopes@nebm.ist.utl.pt:

You could fetch the parent and do the same check, and so on.

Checking only the topmost should be enough if traversing the whole
inheritance could be avoided.

Well, of course I highly second the opinion that not making
distinction and fixing possible bugs in internal classes is a much
better approach.

13 years ago by Patrick ALLAERT — view source

unread

2011/8/25 Sebastian Bergmann sebastian@php.net:

I have attached a patch to https://bugs.php.net/bug.php?id=55490 that
implements ReflectionClass::newInstanceWithoutConstructor() to create an
object a class without invoking the constructor.

As there are certain internal classes that would "crash" when their
constructor is not invoked, this new method of the Reflection API only
works for userland-defined classes.

+1 for the feature

Unless there are objections, I will commit this change to PHP_5_4

+0

and trunk on Monday.

+1

I will add the method to the documentation as well, of
course.

13 years ago by Richard Quadling — view source

unread

I have attached a patch to https://bugs.php.net/bug.php?id=55490 that
implements ReflectionClass::newInstanceWithoutConstructor() to create an
object a class without invoking the constructor.

As there are certain internal classes that would "crash" when their
constructor is not invoked, this new method of the Reflection API only
works for userland-defined classes.

Unless there are objections, I will commit this change to PHP_5_4 and
trunk on Monday. I will add the method to the documentation as well, of
course.

Wouldn't ReflectionClass::newMockInstance() be a better name?

What other use cases exists?

--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea

13 years ago by Sebastian Bergmann — view source

unread

Wouldn't ReflectionClass::newMockInstance() be a better name?

It is not specific to stubbing/mocking.

What other use cases exists?

ORM and stubbing/mocking should be enough.

--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/

13 years ago by Etienne Kneuss — view source

unread

Hi,

I have attached a patch to https://bugs.php.net/bug.php?id=55490 that
implements ReflectionClass::newInstanceWithoutConstructor() to create an
object a class without invoking the constructor.

To me this feature makes no sense. But if people find use for it and
it remains in Reflection, I won't object to it, so +0.

As there are certain internal classes that would "crash" when their
constructor is not invoked, this new method of the Reflection API only
works for userland-defined classes.

I don't believe there should be this artificial distinction. Internal
classes should behave like userland ones in every aspect, let's not
put additional barriers.

If an internal class can't behave well without a constructor call,
that should already be fixed/prevented, as it's already possible by
extending it.

Unless there are objections, I will commit this change to PHP_5_4 and
trunk on Monday. I will add the method to the documentation as well, of
course.

--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/

--

--
Etienne Kneuss
http://www.colder.ch

13 years ago by Sebastian Bergmann — view source

unread

To me this feature makes no sense. But if people find use for it and
it remains in Reflection, I won't object to it, so +0.

It should only be used for meta programming, of course ;-)

If an internal class can't behave well without a constructor call,
that should already be fixed/prevented, as it's already possible by
extending it.

I second that emotion but as long as those internal classes are not
fixed I think it makes sense to disallow creating objects of internal
classes without invoking their constructor.

--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/

13 years ago by Etienne Kneuss — view source

unread

Hi,

To me this feature makes no sense. But if people find use for it and
it remains in Reflection, I won't object to it, so +0.

It should only be used for meta programming, of course ;-)

If an internal class can't behave well without a constructor call,
that should already be fixed/prevented, as it's already possible by
extending it.

I second that emotion but as long as those internal classes are not
fixed I think it makes sense to disallow creating objects of internal
classes without invoking their constructor.

It is already possible to do that currently, with or without this
feature, so you're not preventing much abuse by doing that here. As I
said, artificial distinction.

This feature however alters the necessary checks for missing
constructor calls (at least the ones implemented in SPL as of 5.4), as
those assume a userland subclass.

--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/

--

--
Etienne Kneuss
http://www.colder.ch

13 years ago by Ferenc Kovacs — view source

unread

I have attached a patch to https://bugs.php.net/bug.php?id=55490 that
implements ReflectionClass::newInstanceWithoutConstructor() to create an
object a class without invoking the constructor.

As there are certain internal classes that would "crash" when their
constructor is not invoked, this new method of the Reflection API only
works for userland-defined classes.

Unless there are objections, I will commit this change to PHP_5_4 and
trunk on Monday. I will add the method to the documentation as well, of
course.

--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/

--

hi Sebastian,

would this method give the same result as
unserialize("O:8:"stdClass":0:{}") for example?
I used this trick in the past when I needed to instantiate a class
without calling it's constructor.
of course having a dedicated method for this is much more convenient

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

13 years ago by Sebastian Bergmann — view source

unread

Am 26.08.2011 09:51, schrieb Ferenc Kovacs:

would this method give the same result as
unserialize("O:8:"stdClass":0:{}") for example?

That is the whole point of it, yes.

--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/