On Mon, 11 Apr 2022 at 19:22, Craig Francis <cr...@craigfrancis.co.uk> wrote:
> On Mon, 11 Apr 2022 at 16:14, G. P. B. <george.bany...@gmail.com> wrote: > >> But the implementation caused a Type Error when coercing NULL for >>> everyone (even when not using *strict_types=1*), this seems more of an >>> over-sight >>> >> is utterly wrong and was a conscious design choice based on the widely >> accepted view that nullable by default like Java is a mistake and defeats >> the purpose. >> > > > Bit hash... anyway, I've replaced that paragraph (it wasn't clear enough), > I just wanted to note how developers not using `strict_types=1` would see > it as an over-sight that coercion works for string/int/float/bool but not > null (despite what the documentation says), and how it's introduced a type > check (that they didn't ask for). > > I assume you're using `strict_types=1`, and will be unaffected by this, so > with all due respect, I'm not considering how you view or use NULL, nor do > I care what Java does, I'm simply focused on how most developers use NULL > in PHP. > If I indeed exclusively used strict_types I wouldn't care, but I don't because IMHO strict_types were a mistake and are harmful and induce some self inflicted problems. I've spent a large amount of time making coercive typing mode more sensible and aligning the behaviour as close to reasonably possible with strict_types so that the possibility of dropping strict_types all together wouldn't be outrageous. I've written about this elsewhere and on this list already but main points are located here: https://github.com/Girgias/unify-typing-modes-rfc Userland scalar types, however they would have been introduced, did not include coercion from NULL for *very* good reasons. Wanting to change this behaviour needs more justification than a paragraph in docs, as the docs should reflect the reality of the implementation. The second aspect is the general consensus that internals and userland should behave identically. Which is why the deprecation is here in the first place, to align internal behaviour with the accepted *better* design choice of userland. Your RFC is going against these two pillars. Moreover, the fact that we are deprecating this and not just changing the behaviour from one version to another is that we do recognize PHP developers use NULL in this way, and we are giving them advance notice of the change. Also a deprecation notice should, IMHO, never be promoted to an exception. This is maybe something we need to get better at teaching end users so that they don't pressure library maintainers (or themselves) to fix all of them when they still have a couple of years. Be that either on the php.net docs or elsewhere, to teach end users to either not do this, or at least exclude the vendor directory from their error handler. However, and I cannot stress this enough, we cannot just stop using this tool available to us to steer the language into being better. Because then the other two choices are doing hard breaks with no notice in a major version, or not breaking anything. Both things which are unreasonable to expect. There are behaviours of PHP that will probably never be "fixable", but this should not prevent us from improving the aspects we can. And if we only focused on how developers use PHP we would still have register globals, magic quotes, etc. Clearly it seems you won't listen to why these changes were made and want to reverse course, therefore good luck convincing enough people to accept such an RFC. I think I've said all there is to say and won't interact further with any such proposals. Regards, George P. Banyard
