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.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
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
Hi!
The question is more about the correctness of the doc, and to what I
remember (I implemented thatNULLon failure thing), the doc is wrong.
Well, the question is if '' is an acceptable boolean expressing false or
an error. I could see an argument for either, e.g. if you're having a
config file you could say for boolean config var 'foo_bar=0' and
'foo_bar=' means the same thing, or you could choose the second to be
invalid.
It is a bit complicated by the fact that people are somewhat confused
about the idea that filter_var works on strings, so they think boolean
'false' should be OK with it. Again, if we say foo_bar= is OK, then
false will be OK too, though not because of the reasons some people
think of.
And the null on failure was mainly implemented for this exact case
(boolean validation).
Yeah I understand that, the question is then if '' can be sought as a
valid boolean string meaning false, or as an error. I lean slightly to
the side of '' being accepted, but if somebody has any argument against
it, please let it be heard.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227