On 30/05/2022 15:04, Guilliam Xavier wrote:
For this specific example, shouldn't it rather [already] be like this anyway?
function getByIdentifier(string $identifier) {
if ( $identifier === '' ) {
throw new InvalidArgumentException("Empty identifier");
}
// ...
}
(but I guess you could find actual examples where an empty string is
"valid" and null is not, indeed)
The actual code in this case ended up in a generic routine that used
isset() to choose which SQL to generate. An empty string would generate
a WHERE clause that matched zero rows, but a null would omit the WHERE
clause entirely, and match *all* rows. So an extra pre-validation on the
string format might be useful for debugging, but wouldn't result in
materially different results.
I'm just worried to see people rather disabling deprecation notices
(via error_reporting, or a custom error handler, or even patching
PHP's source and recompiling their own) than "fixing" the code
(granted, that's not specific to*this* RFC, but somewhat "highlighted" here)
Indeed, I think we have a general problem with how deprecations are
communicated and acted on in general. I have been thinking about how to
improve that, other than "never change anything" or "never warn people
we're going to change anything", and will try to write up my ideas soon.
function null_to_empty_string(?string $string_or_null): string
{ return $string_or_null === null ? '' : $string_or_null; }
(but also its "opposite" empty_string_to_null(string $string): ?string)
That's actually an interesting observation. It's probably quite common
to treat empty strings as null when going from input to storage; and to
treat null as empty string when retrieving again. Importantly, databases
generally *don't* treat them as equivalent, so forgetting that
translation can be a real cause of bugs. I often advocate for string
columns in databases to allow either null or empty string, but not both
(by adding a check constraint), so that such bugs are caught earlier.
To go back to Craig's favourite example, that could be a genuine problem
caused by passing null to htmlspecialchars() - if we intended that null
to be stored as such in the database, we've silently converted it into a
non-equivalent empty string. (Yes, escaping should be done on output not
input, but it's not completely infeasible that that combination might
happen.)
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
