On Mon, Feb 7, 2022 at 9:35 AM Mark Randall <marand...@php.net> wrote:
> On 07/02/2022 01:27, Craig Francis wrote: > > I know one person simply said this was a "terribl > idea", but I'm still > > waiting to hear any details on why. > > The changes you propose are not something that I am comfortable with > either. > > I understand your motivations in proposing them, but to my mind it goes > against the direction that PHP is developing, which I think is the right > one, where errors and likely errors result in stopping execution rather > than allowing it continue, potentially silently (dependent on error > handling settings). > > If a parameter expects a string, that is what it should be given, and > its the callers' responsibility to ensure that is the case. If they fail > to do so then it's an error just like any other. > > IMHO reverting to "If it's a null we'll just pretend its a string" is > contrary to how the language should be progressing. > > It sucks that it was ever allowed in the first place. > > PHP has a long history of making descisions to try to make things 'just > work', and if history teaches us anything, its that we inevitably come > to regret these descisions down the line. > I agree with this sentiment. I rather see solutions that solve null values being passed to these functions instead. The in-house legacy framework I use has a small array wrapper that through `ArrayAccess` ensures `null` is returned instead of a notice/warning being thrown when accessing a key that does not exist. During `offsetGet` it will return itself wrapped around the value if it's an array. I'm not saying that this is a good alternative for the problem, it's just one of the solutions that can be taken to tackle issues with `$_POST` and `$_GET` access for example.
