bug #49510

The question is - should we apply it to 5.3/5.4? It is a behavior
change, even though current code behavior does not match documented
behavior.

I understand the concerns of BC, but I don't understand our general reluctance to break BC to fix a bug. What bug fix is not going to also be a behavior change? So long as everything is well-documented, I think most bug fixes should go through right away.

And in cases like this, where there is a clear deviation from the documentation, it's all the more important to fix it, IMHO, because a lot of folks have probably written code that relies on the documented behavior such that their code is now broken and they don't even realize it. Those who identified the deviation in testing and incorporated a workaround probably also notated their code as such so that it's an easy fix later when the bug is fixed - which takes us back to simply documenting fixes very well.

The only time I think holding a bug fix should be a consideration is when the docs aren't clear on the correct behavior, and the behavior is extensively relied upon. By itself, extensive use is not an excuse, IMHO. Other than in the embedded world, code should never be a write-it-and-forget-it-affair... things change in the language, things change in the OS, features are added that are useful, under-used features are removed, security issues are fixed, requirements change, etc., etc. This industry is all about change, and I think most reasonable people are okay with bug fixes that affect BC so long as they're well-documented; they may grumble a bit, but they properly recognize it as a necessary evil. Plus, that's why automated testing is pushed so hard :-).

Those programmers who have code where bug fixes will extensively break things without their knowing it have code that's already a maintenance nightmare, and they probably aren't doing regular PHP upgrades until such time as they get their code under control. Similarly, those who have code that may be fairly lean but is not well-maintained also probably aren't doing regular PHP upgrades. So who, exactly, are we servicing by withholding bug fixes? All we're really doing is making it that much harder to upgrade to future major versions by turning them as much into giant collections of accumulated, BC-breaking bug fixes as they are collections of cool new features.

--
Bob Williams

Notice: This communication, including attachments, may contain information that is confidential. It constitutes non-public information intended to be conveyed only to the designated recipient(s). If the reader or recipient of this communication is not the intended recipient, an employee or agent of the intended recipient who is responsible for delivering it to the intended recipient, or if you believe that you have received this communication in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is prohibited and may be unlawful. If you have received this email in error, please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if any).

hi!

Hi!

We've got a bit of a discussion on bug #49510 in the comments. The
problem is this: filter_var('', FILTER_VALIDATE_BOOLEAN, array("flags"
=> FILTER_NULL_ON_FAILURE)) returns "null" (i.e. failure) while docs say
boolean filter will return false on ''. I think we need to sync with the
docs.
The question is - should we apply it to 5.3/5.4? It is a behavior
change, even though current code behavior does not match documented
behavior.

The question is more about the correctness of the doc, and to what I
remember (I implemented that NULL on failure thing), the doc is wrong.
And the null on failure was mainly implemented for this exact case
(boolean validation).

Cheers,

Pierre

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