On Wed, 29 Jan 2020 at 01:23, tyson andre <tysonandre...@hotmail.com> wrote:
> If a future language change changed the *default* resolution rules for > functions or constants, > I'd rather have future maintainers make the decision on whether to add a > 'fallback' to make migration > than on whether to remove the 'fallback' if it didn't make sense to > support it. > > We have different values and expectations on what's likely to happen in > the future of the language. > I think it's more that we have different understandings of what exists in the language *right now*. In my mind, strict_types has two modes, called 0 and 1; both have fully documented behaviour, and changing either one of them would be a breaking change. At the top of a file, I can specify which of those two modes I want the code to run in. As a convenience, if I don't specify, the code will run in mode 0 - but that doesn't have any implications for what mode 0 means. Similarly, if this RFC is merged, we will have two algorithms for resolving a function name in a namespace; let's call them mode A and mode B. * Mode A is "namespace first, fallback to global". It was first defined in PHP 5.3, and as far as I know hasn't changed since. We don't have to be speculate on how that mode works, we've been writing code in that mode for 10+ years. * Mode B is "global only", and is new in this RFC. In the same way I can specify the strict_types mode, I want to be able to specify at the top of a file whether it should run in mode A or mode B. If I don't specify, it makes sense to assume mode A, but that's just a convenience; it could theoretically give an error telling me to confirm which mode I want. Of course things might change in future: * Someone might add mode C, in which case I can select that for files where I want to use it. * The default mode might change from A to C. All my existing code is written to use mode A, so I want to make sure it continues to run in mode A until I've updated it. * We might deprecate and remove mode A, in which case I'll get log messages for the files where I've specified mode A, telling me to change my code to run in mode B or C. In all of those scenarios, it's an advantage to be able to declare mode A. In none of those scenarios do I get any advantage by specifying "use default mode". > > Can you provide an example of when you'd want to use 'default' instead of > > specifying the mode you've written the file to run in? > > The use cases are similar to the reasons why I'd want to use > strict_types=0. > strict_types=0 is rare in practice. > > 1. Explicitly writing in code that you have chosen on a setting for the > file > and decided not to use 'global'. > 2. Overriding the namespace default if > https://wiki.php.net/rfc/namespace_scoped_declares > gets accepted. > The reason I asked for specific examples is because every single scenario I've thought of so far, whether it's future changes to the language or namespace-scoped declares, would work better with an explicit mode setting, not a 'default' option. For instance, over-riding the namespace default sounds like a plausible use for 'default', but in practice, you wouldn't care which mode was the default for PHP; you would know that this particular file will only run correctly in mode A. So you would specify mode A at the top of the file, not 'default'. I have genuinely tried to come up with a situation where 'default' would be useful, and I have failed. Regards, -- Rowan Tommins [IMSoP]
