> Imagine this scenario: > > * PHP 8 introduces the declare with only 'global' and 'default' options > allowed, as proposed. > * PHP 9 makes 'default' a synonym for 'global', because it's now the > default, and adds a new 'fallback' option > * I have an application that uses the fallback mode > I can either: > > * Rewrite every file in my application prior to upgrading, and add a > declare for 'global' mode to work in PHP 8, even though it will be > redundant on PHP 9 > * Add a declare for 'fallback' mode, meaning my code works on PHP 9 without other changes, but can no longer compile on PHP 8
I'd imagine that if there were significant changes, they would go in the next major version, and PHP 8.X.0 would (or wouldn't) add the new 'fallback' option and possibly emit deprecation notices about the 'default' option or the absence of an option. (Possibly only if the file did have any ambiguous function/const references) So done that way, you could run the same code both on the latest release of PHP 8.x and PHP 9.0. 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'd imagine the migration to 8.0 and 9.0 would be similar to 5.6 to 7.0: https://www.php.net/supported-versions.php - PHP 5.6 had an extended security support timeline, to give users time to update to php 5.6, validate and migrate to 7.0. The timeline for the release prior to 8.0 would probably reflect how hard it would be to migrate. - Many things deprecated in PHP 5.x were removed in 7.0 > Explicitly selecting a default for some value is useful when any value > would actually be acceptable, and you want to delegate the choice of > value to someone else. That's how PASSWORD_DEFAULT works, for instance - > it means "please select a sane algorithm based on the current state of > the world". I don't think that applies here - any file will have been > written with one set of rules in mind, so "use whichever namespace rules > are currently recommended" doesn't really make sense as an option IMO. 'default' is more of a way to explicitly indicate you have made a decision on the option for this file, and deliberately aren't using it for the file. It's just a better name than the others I could possibly come up with ('unchanged', 0, etc) 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, I doubt that there would be an argument for creating `strict_types='php7'` before we knew what those changes are, if there would be changes at all, and what the tradeoffs to supporting the php 7 semantics are. `strict_types=0` would be used more often if the namespace-scoped declare() RFC was accepted. - Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
