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.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
hi,
Referring to:
https://bugs.php.net/bug.php?id=55300
and in some extend to https://bugs.php.net/bug.php?id=55175I 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=55175I 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
hi,
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).
Please do the revert, as you did the commit in the 1st place. As far
as I remember we have discussed this issue back then already as well.
But even in 5.3, there are in SPL counter-measures that don't work
reliably, like making a check in get_method.
Right, but that's another concern and the same cautiousness should be
taken there.
Thanks!
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org