# PHP 5.3.8 Released! - Thread: https://externals.io/message/54824 - Original archive: https://news-web.php.net/php.internals/54824 - Started by johannes@php.net on 2011-08-23T16:08:02+00:00 - Messages: 55 - Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/54824.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #54824 — johannes@php.net — 2011-08-23T16:08:02+00:00 URL: https://externals.io/message/54824#54824 The PHP development team would like to announce the immediate availability of PHP 5.3.8. This release fixes two issues introduced in the PHP 5.3.7 release: * Fixed bug #55439 (crypt() returns only the salt for MD5) * Reverted a change in timeout handling restoring PHP 5.3.6 behavior, which caused mysqlnd SSL connections to hang (Bug #55283). All PHP users should note that the PHP 5.2 series is NOT supported anymore. All users are strongly encouraged to upgrade to PHP 5.3.8. For source downloads please visit our downloads page at , Windows binaries can be found on . Johannes Schlüter PHP 5.3 Release Master --- ## #54837 — alan@akbkhome.com — 2011-08-24T01:57:00+00:00 URL: https://externals.io/message/54824#54837 · In reply to: #54824 It might have been better to have waited for the `is_a()` fix to get sorted out.. - It's a very annoying BC break (changes the documented behaviour), and now it means we need 4.3.9 in a few more days. Let me know if you need help testing / applying etc.. Regards Alan > The PHP development team would like to announce the immediate > availability of PHP 5.3.8. This release fixes two issues introduced in > the PHP 5.3.7 release: > > * Fixed bug #55439 (crypt() returns only the salt for MD5) > * Reverted a change in timeout handling restoring PHP 5.3.6 > behavior, which caused mysqlnd SSL connections to hang (Bug > #55283). > > All PHP users should note that the PHP 5.2 series is NOT supported > anymore. All users are strongly encouraged to upgrade to PHP 5.3.8. > > For source downloads please visit our downloads page at > , Windows binaries can be found on > . > > Johannes Schlüter > PHP 5.3 Release Master --- ## #54844 — Ferenc Kovacs — 2011-08-24T07:44:08+00:00 URL: https://externals.io/message/54824#54844 · In reply to: #54837 > It might have been better to have waited for the `is_a()` fix to get sorted > out.. - It's a very annoying BC break (changes the documented behaviour), > and now it means we need 4.3.9 in a few more days. > > Let me know if you need help testing / applying etc.. > from what I understand, this won't be changed, as the current behavior is correct, the old was a bug: as Stas pointed out: "Not a bug. $var is interpreted as a class name. To know if one class extends another, the class in question (first one) should be loaded. There's no need to load the second one since if it's unknown nothing can be instance of it and existing classes can not extend it." if you used this previously from Dmitry: "Before the patch, `is_a()` didn't accept string as the first argument at all, so it always returned "false" and never triggered __autoload(). The proposed patch didn't revert to original behavior. It just disables autoloading and may lead to wrong result. class a {} class b extends a {} var_dump(is_a("b", "a")); // it was false before 5.3.7, now it's true I would say that the old behaviour was wrong, especially because "instanceof" and `is_subclass_of()` already implemented support for string arguments." so your example was bogus, as passing a non-object as a first parameter wasn't supported (see http://php.net/is_a) so your code example depends on an undefined behavior and results in a bogus result (is_a() alwas returned false if you passed a non-object) so in a way it is really a BC, but I think that this change is really a bugfix. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #54845 — Sebastian Bergmann — 2011-08-24T08:06:23+00:00 URL: https://externals.io/message/54824#54845 · In reply to: #54837 > It might have been better to have waited for the `is_a()` fix to get sorted > out. No, it would have been better if the only difference between PHP 5.3.7 and PHP 5.3.8 would have been the fix for the `crypt()` issue. -- Sebastian Bergmann Co-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ --- ## #54851 — Reindl Harald — 2011-08-24T08:51:54+00:00 URL: https://externals.io/message/54824#54851 · In reply to: #54845 Am 24.08.2011 10:06, schrieb Sebastian Bergmann: > > > […] > > No, it would have been better if the only difference between PHP 5.3.7 > and PHP 5.3.8 would have been the fix for the `crypt()` issue it was and additionally the break of mysqlnd/mysql-over-ssl was reverted which killed ALL our setups and forced me to play around with ssh-tunnels between servers what is nothing you like to do for some months because you are killing 127.0.0.1-restrictions on the target-machine * Fixed bug #55439 (crypt() returns only the salt for MD5) * Reverted a change in timeout handling restoring PHP 5.3.6 behavior, which caused mysqlnd SSL connections to hang (Bug #55283). --- ## #54852 — Derick Rethans — 2011-08-24T09:36:04+00:00 URL: https://externals.io/message/54824#54852 · In reply to: #54844 > > > […] > > from what I understand, this won't be changed, as the current behavior > is correct, the old was a bug: It is also a BC break! Yes, it should be fixed, but only in 5.4. This kind of little changes is what makes people look at PHP as a joke! Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #54853 — alan@akbkhome.com — 2011-08-24T09:37:28+00:00 URL: https://externals.io/message/54824#54853 · In reply to: #54844 Since when has changing documented behaviour and breaking a large number of applications been acceptable? (Well, happens occasionally by accident ..) This was a 'feature change' to `is_a()`, it was documented as _only_ returning 'TRUE' when an object was passed as the first object and it was an instance of that... I did read through the previous posts, (just caught up the other day), it looks like if anybody really need to do what this new feature provides, (which is probably very rare), then $left == $right || is_subclass_of($left,$right) should work fine without breaking any code. Regards Alan > > > […] > from what I understand, this won't be changed, as the current behavior > is correct, the old was a bug: > > as Stas pointed out: > "Not a bug. $var is interpreted as a class name. To know if one class > extends another, the class in question (first one) should be loaded. > There's no need to load the second one since if it's unknown nothing > can be instance of it and existing classes can not extend it." > if you used this previously > > from Dmitry: > "Before the patch, `is_a()` didn't accept string as the first argument > at all, so it always returned "false" and never triggered > __autoload(). The proposed patch didn't revert to original behavior. > It just disables autoloading and may lead to wrong result. > > class a {} > class b extends a {} > var_dump(is_a("b", "a")); // it was false before 5.3.7, now it's true > > I would say that the old behaviour was wrong, especially because > "instanceof" and `is_subclass_of()` already implemented support for > string arguments." > > so your example was bogus, as passing a non-object as a first > parameter wasn't supported (see http://php.net/is_a) so your code > example depends on an undefined behavior and results in a bogus result > (is_a() alwas returned false if you passed a non-object) > > so in a way it is really a BC, but I think that this change is really a bugfix. --- ## #54854 — Ferenc Kovacs — 2011-08-24T09:50:45+00:00 URL: https://externals.io/message/54824#54854 · In reply to: #54852 > > > > […] > > It is also a BC break! Yes, it should be fixed, but only in 5.4. This > kind of little changes is what makes people look at PHP as a joke! > agree with keeping the BC as much as possible, but from the responses from the others (Dmitry, Stas, Zeev) and the nature of the change (changing the undefined behavior of the function) and the fact that it is already out there (and changing this back and releasing a new version now or later would be even more wrong) my guess is that we will keep the new behavior. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #54855 — Pierre Joye — 2011-08-24T10:00:31+00:00 URL: https://externals.io/message/54824#54855 · In reply to: #54852 agreed. > > > > […] > > It is also a BC break! Yes, it should be fixed, but only in 5.4. This > kind of little changes is what makes people look at PHP as a joke! > > Derick > > -- > http://derickrethans.nl | http://xdebug.org > Like Xdebug? Consider a donation: http://xdebug.org/donate.php > twitter: @derickr and @xdebug > > -- > > > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #54856 — Ferenc Kovacs — 2011-08-24T10:24:00+00:00 URL: https://externals.io/message/54824#54856 · In reply to: #54855 > agreed. > about this specific change: the real problem is that nobody spotted this change until we rolled out the stable release, after that we can only chose from bad options. we could have spotted this via two ways: - those who participated in fixing https://bugs.php.net/bug.php?id=53727 could have spotted this - our tests should have start failing after the change AFAIK non of that happened, and fixing the first is hard, so I would propose fixing the second (I know, it is already agreed and worked toward) another problem is that the current(and before the change also) proto was not forced by the function, so if `is_a()` would raise warnings when non-object is passed to the first argument, this BC break would have much less impact. so I got the idea that it would be usefull, if somebody could write a script which fetches the proto for the functions/methods and does some fuzzing which checks if the protos are enforced. after that, we would have a list, and probably we could fix those (changing the proto and the docs to the real behaviour, or vica versa), and we could see whether the fix would impy BC and for those cases we could just keep it as is for the stable branch and create tests which would guarantee that changing the current behavior in the stable branch wouldn't go unnoticed. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #54857 — Pierre Joye — 2011-08-24T10:36:59+00:00 URL: https://externals.io/message/54824#54857 · In reply to: #54856 the problem is to change existing tests to match a "possible fix", that defeats the whole purpose of testing possible BC breaks using our test suites. We should definitively run x.y.0 tests during the whole x.y.0 life, and if something has to be changed, then it should be 1st be discussed, or RFC for big changes. And then it should indeed be documented as well, in the UPGRADING guide (should be done anyway for x.y+1 versions too). > > > […] > > about this specific change: > the real problem is that nobody spotted this change until we rolled > out the stable release, after that we can only chose from bad options. > we could have spotted this via two ways: > - those who participated in fixing > https://bugs.php.net/bug.php?id=53727 could have spotted this > - our tests should have start failing after the change > > AFAIK non of that happened, and fixing the first is hard, so I would > propose fixing the second (I know, it is already agreed and worked > toward) > > another problem is that the current(and before the change also) proto > was not forced by the function, so if `is_a()` would raise warnings when > non-object is passed to the first argument, this BC break would have > much less impact. > > so I got the idea that it would be usefull, if somebody could write a > script which fetches the proto for the functions/methods and does some > fuzzing which checks if the protos are enforced. > after that, we would have a list, and probably we could fix those > (changing the proto and the docs to the real behaviour, or vica > versa), and we could see whether the fix would impy BC and for those > cases we could just keep it as is for the stable branch and create > tests which would guarantee that changing the current behavior in the > stable branch wouldn't go unnoticed. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #54858 — johannes@schlueters.de — 2011-08-24T10:42:04+00:00 URL: https://externals.io/message/54824#54858 · In reply to: #54856 > we could have spotted this via two ways: > - those who participated in fixing > https://bugs.php.net/bug.php?id=53727 could have spotted this > - our tests should have start failing after the change Third option: - RC testers might have spotted and reported it. I have the impression that very few people actually test these. When creating an RC we inform the "primary testers" as well as qa and internals list members. From there I get one or two responses in general. When I approach PHP users I often get answers like installing PHP without breaking their setup would be complicated (which is not the case but maybe needs education?) and they won't have time. I try to use a hypothetical case, like we have here in reality, to explain them why it is beneficial for their business if it is detected early as then we can fix it, fixing something after a release is hard. We also can try to improve our tests but we will never be able to test each and every way PHP is being used out there in the wild. So how can we motivate people to test new versions during RC not the day after it is being released? We don't push them out as news on the php.net frontpage and we don't send it out to the announce list for reasons like not confusing users. Should we change that? Other ideas? johannes --- ## #54859 — Zeev Suraski — 2011-08-24T10:43:05+00:00 URL: https://externals.io/message/54824#54859 · In reply to: #54853 I think there are two ways to look at it: - As a new feature. If I understand you correctly, the fact that beforehand `is_a()` was documented to only return `TRUE` in case the first argument was an instance of the second argument, means that if we do anything beyond that - e.g. support strings as the first argument - this means we break compatibility (please correct me if I misunderstood). IMHO that's not a realistic way to look at retaining compatibility, and I'm saying that as someone who's almost religious about maintain compatibility. With that view of the world, almost every bug fix and literally every feature we add - breaks compatibility. - As a bug fix. Strings were supported even before this change, but they weren't working properly or consistently with the way classes work everywhere else in PHP. That was fixed. Just so that we feel good about ourselves, we also changed undocumented behavior. In case it's not clear, a situation where is_a("bar", "foo") returns FALSE, even though bar extends foo, but bar simply doesn't happen to be loaded in memory at the time of the call - can lead to very real world bugs. Zeev > -----Original Message----- > From: alan@akbkhome.com [mailto:alan@akbkhome.com] > Sent: Wednesday, August 24, 2011 12:37 PM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] PHP 5.3.8 Released! > > Since when has changing documented behaviour and breaking a large > number of applications been acceptable? (Well, happens occasionally by > accident ..) > > This was a 'feature change' to `is_a()`, it was documented as _only_ returning > 'TRUE' when an object was passed as the first object and it was an instance of > that... > > I did read through the previous posts, (just caught up the other day), it looks > like if anybody really need to do what this new feature provides, (which is > probably very rare), then > > $left == $right || is_subclass_of($left,$right) > > should work fine without breaking any code. > > Regards > Alan > > > > […] > alan@akbkhome.com wrote: > > […] > > > -- > To unsubscribe, visit: > http://www.php.net/unsub.php --- ## #54860 — Dirk Haun — 2011-08-24T11:04:29+00:00 URL: https://externals.io/message/54824#54860 · In reply to: #54858 Quoting Johannes Schlüter : > I have the impression that very few people actually test these. When > creating an RC we inform the "primary testers" as well as qa and > internals list members. From there I get one or two responses in > general. What happens to the reports that "make test" sends back to php.net? There are always a few tests failing (I don't think I ever installed a PHP version - final or not - that didn't have at least one or two failing tests). Where do those reports end up and is anyone actually looking at them? bye, Dirk --- ## #54861 — Ferenc Kovacs — 2011-08-24T11:08:13+00:00 URL: https://externals.io/message/54824#54861 · In reply to: #54858 2011/8/24 Johannes Schlüter : > > > […] > > Third option: > - RC testers might have spotted and reported it. > > I have the impression that very few people actually test these. When > creating an RC we inform the "primary testers" as well as qa and > internals list members. From there I get one or two responses in > general. > > When I approach PHP users I often get answers like installing PHP > without breaking their setup would be complicated (which is not the case > but maybe needs education?) and they won't have time. I try to use a > hypothetical case, like we have here in reality, to explain them why it > is beneficial for their business if it is detected early as then we can > fix it, fixing something after a release is hard. We also can try to > improve our tests but we will never be able to test each and every way > PHP is being used out there in the wild. > > > So how can we motivate people to test new versions during RC not the day > after it is being released? > > > We don't push them out as news on the php.net frontpage and we don't > send it out to the announce list for reasons like not confusing users. > Should we change that? Other ideas? > > johannes agree, should have mentioned that. I think that currently testing the RCs have a very high barrier. usually they are going unnoticed for most people and compiling your own version (with all the extensions that you need) can be really cumbersome. - we need to get out the word to the masses (the current php.net site simply lacks this, maybe the http://prototype.php.net/ will be better in this regard), for which we also need to lower the barriers to entry: - better documentation about how to build your own php version would be a must, maybe phpfarm can be also useful for this - we should cooperate with the major php projects out there to run their testsuites against the new releases or maybe even trunk, if I remember correctly somebody mentioned that we already do this for some projects (maybe Pierre mentioned this). this would be an easy way to boost our test coverage and make the BC breaks more obvious. - having pre-packaged versions of php available would also help, testing out the latest mysql versions are much more easy for example, as I can just grab the Linux - Generic archive, extract it, and voila, I can test it. - projects like http://apt.damz.org/ also help -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #54862 — Ferenc Kovacs — 2011-08-24T11:16:05+00:00 URL: https://externals.io/message/54824#54862 · In reply to: #54860 > Quoting Johannes Schlüter : > > > […] > > What happens to the reports that "make test" sends back to php.net? There > are always a few tests failing (I don't think I ever installed a PHP version > - final or not - that didn't have at least one or two failing tests). > > Where do those reports end up and is anyone actually looking at them? they are sent to the qa reports mailing list: http://news.php.net/php.qa.reports the aggregated report summaries are available at http://qa.php.net/reports/ thanks to Oliver Doucet who make this happen. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #54863 — Pierre Joye — 2011-08-24T11:23:15+00:00 URL: https://externals.io/message/54824#54863 · In reply to: #54859 > I think there are two ways to look at it: > > - As a new feature.  If I understand you correctly, the fact that beforehand `is_a()` was documented to only return `TRUE` in case the first argument was an instance of the second argument, means that if we do anything beyond that - e.g. support strings as the first argument - this means we break compatibility (please correct me if I misunderstood).  IMHO that's not a realistic way to look at retaining compatibility, and I'm saying that as someone who's almost religious about maintain compatibility.  With that view of the world, almost every bug fix and literally every feature we add - breaks compatibility. > > - As a bug fix.  Strings were supported even before this change, but they weren't working properly or consistently with the way classes work everywhere else in PHP.  That was fixed.  Just so that we feel good about ourselves, we also changed undocumented behavior.  In case it's not clear, a situation where is_a("bar", "foo") returns FALSE, even though bar extends foo, but bar simply doesn't happen to be loaded in memory at the time of the call - can lead to very real world bugs. No matter what it is or how it is defined by us, it breaks existing code and that should be avoided in bug fixes releases like 5.3.7/8. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #54864 — Alexey Shein — 2011-08-24T11:28:03+00:00 URL: https://externals.io/message/54824#54864 · In reply to: #54861 2011/8/24 Ferenc Kovacs : > 2011/8/24 Johannes Schlüter : > > […] > > agree, should have mentioned that. > I think that currently testing the RCs have a very high barrier. > usually they are going unnoticed for most people and compiling your > own version (with all the extensions that you need) can be really > cumbersome. > - we need to get out the word to the masses (the current php.net site > simply lacks this, maybe the http://prototype.php.net/ will be better > in this regard), for which we also need to lower the barriers to > entry: > - better documentation about how to build your own php version would > be a must, maybe phpfarm can be also useful for this I would really glad to have a script that will be eager to enable as much modules as it can find on my machine (plus enable debug flags as --enable-zts-maintainer and such) and even offer to install some missing dependencies from OS packages (I'm on ubuntu so it's easy to do some apt-get/yum install if you know what are you for). For now you have to read quite a long list of configure options and then install their dependencies which are quite non-obvious to find out. > - we should cooperate with the major php projects out there to run > their testsuites against the new releases or maybe even trunk, if I > remember correctly somebody mentioned that we already do this for some > projects (maybe Pierre mentioned this). this would be an easy way to > boost our test coverage and make the BC breaks more obvious. > - having pre-packaged versions of php available would also help, > testing out the latest mysql versions are much more easy for example, > as I can just grab the Linux - Generic archive, extract it, and voila, > I can test it. > - projects like http://apt.damz.org/ also help > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu > > -- > > > > -- Regards, Shein Alexey --- ## #54865 — alan@akbkhome.com — 2011-08-24T11:35:04+00:00 URL: https://externals.io/message/54824#54865 · In reply to: #54859 It's not really a bug fix, as the document for `is_a()` never said it would support 'mixed' first argument. (is_subclass_of is different, it currently says mixed as the first argument). If it needed fixing, then support for strings should have been removed, rather than added. The problem I have is that this 'feature' is not really that usefull, to anyone AFAIKS. (why would you realistically want to do that kind of check?) and if you really did need to do such a test, there are other trivial ways to do it already (which work across versions). I know it's reusing code at the backend, but it's a trivial change to remove the BC break, and it does not break anything else. (nobody would have used it that way yet..). Regards Alan > I think there are two ways to look at it: > > - As a new feature. If I understand you correctly, the fact that beforehand `is_a()` was documented to only return `TRUE` in case the first argument was an instance of the second argument, means that if we do anything beyond that - e.g. support strings as the first argument - this means we break compatibility (please correct me if I misunderstood). IMHO that's not a realistic way to look at retaining compatibility, and I'm saying that as someone who's almost religious about maintain compatibility. With that view of the world, almost every bug fix and literally every feature we add - breaks compatibility. > > - As a bug fix. Strings were supported even before this change, but they weren't working properly or consistently with the way classes work everywhere else in PHP. That was fixed. Just so that we feel good about ourselves, we also changed undocumented behavior. In case it's not clear, a situation where is_a("bar", "foo") returns FALSE, even though bar extends foo, but bar simply doesn't happen to be loaded in memory at the time of the call - can lead to very real world bugs. > > Zeev > > > […] --- ## #54866 — Zeev Suraski — 2011-08-24T11:38:25+00:00 URL: https://externals.io/message/54824#54866 · In reply to: #54865 Alan, I think this feature can certainly be useful, but either way, but again, unless I'm misunderstanding you - you're defining new functionality (support for new types of a first argument) as a BC break. I don't think it's realistic to look at it this way. And I do think that it's useful, assuming you don't have typos and ask about non-existent classes, or have a broken autoloader - this will work as expected and return true/false properly. Zeev > -----Original Message----- > From: alan@akbkhome.com [mailto:alan@akbkhome.com] > Sent: Wednesday, August 24, 2011 2:35 PM > To: Zeev Suraski > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] PHP 5.3.8 Released! > > It's not really a bug fix, as the document for `is_a()` never said it would support > 'mixed' first argument. (is_subclass_of is different, it currently says mixed as > the first argument). If it needed fixing, then support for strings should have > been removed, rather than added. > > The problem I have is that this 'feature' is not really that usefull, to anyone > AFAIKS. (why would you realistically want to do that kind of > check?) and if you really did need to do such a test, there are other trivial > ways to do it already (which work across versions). > > I know it's reusing code at the backend, but it's a trivial change to remove the > BC break, and it does not break anything else. (nobody would have used it that > way yet..). > > Regards > Alan > > > > […] > `is_a()` was documented to only return `TRUE` in case the first argument was an > instance of the second argument, means that if we do anything beyond that - > e.g. support strings as the first argument - this means we break compatibility > (please correct me if I misunderstood). IMHO that's not a realistic way to look > at retaining compatibility, and I'm saying that as someone who's almost > religious about maintain compatibility. With that view of the world, almost > every bug fix and literally every feature we add - breaks compatibility. > > […] > weren't working properly or consistently with the way classes work > everywhere else in PHP. That was fixed. Just so that we feel good about > ourselves, we also changed undocumented behavior. In case it's not clear, a > situation where is_a("bar", "foo") returns FALSE, even though bar extends foo, > but bar simply doesn't happen to be loaded in memory at the time of the call - > can lead to very real world bugs. > > […] > days. > > […] > visit: > > […] --- ## #54867 — Zeev Suraski — 2011-08-24T11:40:17+00:00 URL: https://externals.io/message/54824#54867 · In reply to: #54863 > No matter what it is or how it is defined by us, it breaks existing code and that > should be avoided in bug fixes releases like 5.3.7/8. Pierre, This wholesale statement doesn't get us anywhere. Every bug fix can result in breaking existing code. If due to a logic error, under some circumstances - `file_exists()` returned false for a file that actually exists, are we barred from fixing that in a maintenance release? Obviously not. What about bug # 54459? What if some piece of code out there relied on this behavior? What about # 55082 - what if someone already relied on this and wrote a layer to alter the output accordingly? Since clearly the definition of never breaking existing code, no matter how far-fetched it may be, means we can't do just about anything in bug fix releases - we need to set slightly more realistic definitions. The fix for `is_a()` falls squarely within the realm of stuff we should be doing in bug fix releases, IMHO. It is a bug fix, bug fixes by definition change behavior - sometimes to the degree of breaking certain (broken) pieces of code. Zeev --- ## #54868 — Pierre Joye — 2011-08-24T11:44:50+00:00 URL: https://externals.io/message/54824#54868 · In reply to: #54867 > > […] > > Pierre, > > This wholesale statement doesn't get us anywhere. It does, we underestimate the situation and this fix/improvement/consistency change breaks apps and codes out there. And I do not consider it as acceptable at this stage in 5.3.x. Let do it only in 5.4. > Every bug fix can result in breaking existing code. Not every, and here it is easily fixable. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #54869 — Ryan McCue — 2011-08-24T11:59:13+00:00 URL: https://externals.io/message/54824#54869 · In reply to: #54862 Ferenc Kovacs wrote: > the aggregated report summaries are available at > http://qa.php.net/reports/ thanks to Oliver Doucet who make this > happen. > Which, incidentally, doesn't appear to be working at this point in time. -- Ryan McCue > […] > > It does, we underestimate the situation and this fix/improvement/consistency > change breaks apps and codes out there. > And I do not consider it as acceptable at this stage in 5.3.x. Let do it only in > 5.4. How is it different from any of the other non-crash-fixing bugs we fixed, that could break apps that relied on the old behavior? Gave you two examples from the last release (well, 5.3.7), and another imaginary one. They all fall in the category of potentially breaking code out there, and yet - they should all be fixed. > > […] > > Not every, and here it is easily fixable. I'll refrain from word fighting you on the first part, but on the second - how is it easily fixable? This: is_a("bar", "foo"); // false $obj = new bar; is_a($obj, "foo"); // true, since now that bar's been loaded we know it extends foo Is a language bug, and a pretty bad one too. Zeev --- ## #54871 — Ferenc Kovacs — 2011-08-24T12:04:15+00:00 URL: https://externals.io/message/54824#54871 · In reply to: #54869 > Ferenc Kovacs wrote: > > […] > > Which, incidentally, doesn't appear to be working at this point in time. it was working when I sent the mailt. it would be a weird coincidence... -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- Next page: https://externals.io/message/54824.md?page=2