On 22/09/11 01:41, Alan Knowles wrote:

To clarify

* Code changed to work around this change will not break if it is reverted.
Basically it is to add is_object() before any call to is_a()

* If left as is, there is reasonable potential for remote exploits in
many codebases.

* This change is not really in the wild yet, as people do not upgrade
that fast, and as mentioned distro's are avoiding upgrading due to the
rather serious consequences.

* This code affects anyone using the autoloader (PSR or other) with any
existing codebase (for example Joomla will probably break if used with
an autoloader)

* The 'revert' BC break will only affect someone who
a) uses undocumented behaviors which are only known about due to reading
this list.
b) has written code specifically targeting this controversial behavior
in the last few weeks.

* Nobody who has argued for keeping this change has made any commits or
bug reports to any package (as far as I know) to help fix code affected
by the change.

* is_a() in it's previous usage was 'useful', and resulted in clear
consise code. now practically every use of the code has to be prefixed
with is_object(). This is wastefull and pointless, and more prone to
errors.


Saying that 'breaking BC again' should not be done is an utterly bogus
argument. Please understand the issue properly before coming up with
such a ridiculous comment. The point of 'not breaking BC' is to stop
breaking existing code which has been running for years, not breaking
code that has been created 10 minutes ago. Please be realistic here.



Hi,

Just for the record:

For Gentoo, we actually did ship PHP 5.3.8, resulting in a little storm of users being very upset about us breaking their code. Especially since PEAR packages started breaking.

Wearing my package maintainer hat and given that Alan's points above are true, I would very much like for is_a's behaviour to be reverted to pre-5.3.8 state as well. I also believe that reverting would cause less damage than keeping current behaviour.

Cheers,
Ole Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to