On 19/04/2022 12:34, Craig Francis wrote:
The developers I work with would assume the last definition
I think you've somewhat missed my point. I wasn't talking about people's
habits or preferences, I was talking about different *scenarios* where
null is used to mean different things.
Yes, some people prefer languages that "fails early" and some are more
interested in "do what I mean", but not everything is about that.
I also cannot explain why NULL should be rejected ... does it avoid
any bugs?
Yes, sometimes. Imagine an array of values provided by the user; during
validation, those which were optional and not provided get set to null.
You then loop through and display those which were provided:
foreach ( $fields as $name => $value ) {
if ( $value !== null ) {
echo "<strong>$name:</strong> $value <br>\n";
}
}
Then, you realise you forgot about escaping, and decide to run
everything through htmlspecialchars():
$htmlFields = array_map('htmlspecialchars', $fields);
foreach ( $htmlFields as $name => $value ) {
if ( $value !== null ) {
echo "<strong>$name:</strong> $value <br>\n";
}
}
Spot the bug? $value will now never be null, because htmlspecialchars()
will silently turn the nulls into empty strings.
I've also seen the opposite problem: a string function was removed
because it was no longer needed, and the code broke because values,
including nulls, were no longer being cast to string.
Is protecting against this worth the backwards compatibility cost of
changing the behaviour, and requiring extra code in other scenarios?
Possibly not. But that's different from not having any benefit.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
