Re: [RFC] "use global functions/consts" statement

On 28/01/2020 01:06, tyson andre wrote:

I don't plan to change the default name resolution behavior in PHP 9, though, and if it does change, it might even be according to a different proposal, so adding 'fallback' as a third option before we know what type of change is planned seems premature.

I still don't understand this logic. If my code is written so that it needs the current "same namespace fallback to global" behaviour, I don't care what the default mode is, or how many other modes there are, I want to make sure that file will continue to use that mode. The *only* way to do that is if there is a directive saying *explicitly* that I want that mode. In other words, we don't need to know what the future modes are to know what modes we have *right now*, and give those modes names.

I'd imagine the migration to 8.0 and 9.0 would be similar to 5.6 to 7.0

That's not the point; people want to be able to run the same code on multiple versions; the sooner we include a forwards-compatible option, the more versions code referencing that option can run on. I'm not seeing the downside of adding it now.

I see strict_types=0 as similar - The value 0 is currently rarely used compared to leaving out the setting. If php 8.x were to become stricter about type casting by default in a few ways,

The difference is that we could change the default in a future version to be strict_types=1, and people could run code with strict_types=0 on both versions with exactly the same effects. That's not the same as saying strict_types='default'.

I doubt that there would be an argument for creating strict_types='php7' before we knew what those changes are,

We already have created that: strict_types=0 and strict_types=1 can retain their current meaning, and any new mode can have a new name (strict_types=2, strict_types='php9', whatever). To be clear, I'm not suggesting 'fallback' is added as a third option, I'm saying we should name the two options 'fallback' and 'global', just like strict_types has two options, 0 and 1. I can't think of any situation where I would want a change to the default mode in the engine to cause my code to be interpreted in a different way, so a 'default' option makes no sense to me. Regards, -- Rowan Tommins (né Collins) [IMSoP]