BC break in 5.4, extending internal class

hi,

Referring to:

https://bugs.php.net/bug.php?id=55300
and in some extend to https://bugs.php.net/bug.php?id=55175

I tend to think that it could have a very bad impact on existing and
will prevent many users to migrate easily to 5.4, or smoothly. I think
we have to figure a fix for this problem while making it 100% BC with
5.3. I'd to discuss this problem before we go with the 1st RC.

Pierre,

Is it too much deviation to auto-call the DirectoryIterator
constructor if the dev made a __construct() in the child class but
didn't call the parent construct(), ONLY when the DirectoryIterator's
functionality is referenced. Aka a lazy-load check.

It's a silent call, and i'm not in favour of silent stuff but maybe
this has sparked a few ideas for people reading this discussion to
come up with a less magic solution.

Regards,
Paul Dragoonis.

Cheers,

Pierre

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

Em Mon, 24 Oct 2011 14:53:07 +0100, Pierre Joye pierre.php@gmail.com
escreveu:

https://bugs.php.net/bug.php?id=55300
and in some extend to https://bugs.php.net/bug.php?id=55175

I tend to think that it could have a very bad impact on existing and
will prevent many users to migrate easily to 5.4, or smoothly. I think
we have to figure a fix for this problem while making it 100% BC with
5.3. I'd to discuss this problem before we go with the 1st RC.

(context: this is the problem of calling internal methods on objects that
were not properly constructed).

The change I did in 5.4 should be reverted and synced with 5.3 in the
short term because it doesn't work reliably (even not considering the BC
break) -- there are other methods for getting an invalid instance (the new
reflection method and unserialize, at least).

But even in 5.3, there are in SPL counter-measures that don't work
reliably, like making a check in get_method.

Last month, Etienne was exploring the possibilities for this problem, but
I don't think he got to any good solution. In the medium term, either
direct calls to zend_object_store_get_object are banned and every method
goes through a class-specific wrapper or we come up with a better solution
(the only think I came up with in the discussion last time was enforcing
the restriction on zend_do_fcall_common_helper/zend_call_function by
calling a validation callback stored in the class_entry every time an
internal method is to be called).

--
Gustavo Lopes