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

> 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. If strict_types had a name instead of a number, we'd have a similar argument over whether there should be a strict_types='off' vs ='default' and strict_types='on' 'default' is the option I'd consider the best for what I consider to be likely ways php will/won't change. I can > I'm not seeing the downside of adding it now. - Confusion by new developers over whether 'fallback' is weaker than omitting the option. - Obliging future maintainers to potentially support whatever 'fallback' would be understood to be if PHP's name resolution changes in a minor way. (e.g. if count() uses a keyword that's always the global function, like empty() currently does, as an unrealistic/undesirable example) > 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'. If php changes the default casting behavior to forbid weak casting boolean to string or string to boolean (as another unrealistic example), I personally wouldn't expect strict_types=0 to be required to allow it. In that case, both versions wouldn't have the same effects. Discussions on such a change may reasonably differ in those expectations. > > 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. I have a better understanding of why you're asking for this now, but still prefer 'default' and 'global' for the reasons I've mentioned. ________________________________________ From: Rowan Tommins <rowan.collins@gmail.com> Sent: January 28, 2020 4:06 AM To: internals@lists.php.net Subject: Re: [PHP-DEV] [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] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php