On Fri, Nov 10, 2023 at 1:33 PM Craig Francis <cr...@craigfrancis.co.uk> wrote:
>
> On 10 Nov 2023, at 12:16, Andreas Leathley <a.leath...@gmx.net> wrote:
> > Also note that in your example $q could be an array (leading to a fatal
> > error in the code)from the request data, which is why checking types
> > thoroughly (not just coercing them with strval) can be helpful in avoiding
> > unexpected situations and deciding how to handle such situations, instead
> > of yolo-ing it.
>
> Yep, and I completely agree, but I'm not focusing on my code, I'm looking at
> the code the vast majority of developers write... and I do not want PHP 9 to
> be so difficult to use that people stay on PHP 8 forever.
>
> Craig
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
Personally, I find the whole strict types + nullable thing really bad.
(string) null is "", which is hopefully pretty well known. But with
strict types, you may not even know you have a null value because
casting is used all over the code base. I constantly have to point out
this in code reviews and suggest this:
// val is an int|string|null
func((string) ($val ?? throw new LogicException("val should not be null")));
which just feels dirty. At least in non-strict type mode, we would get
"null catching" for free (at the expense of deterministic coercion),
and is one reason we're actually considering to switch back to
non-strict types; a very simple coercion system for everything but
null.
So, really, I think it might be a good idea to rethink the whole type
system at some point. There isn't really any ideal solution atm for
handling nulls + strict types.
Robert Landers
Software Engineer
Utrecht NL
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
