On 27/01/2020 14:43, tyson andre wrote:
I'd rather have that done when the future change of defaults is being proposed.
Supporting 'fallback' might cause confusion and extra work if the name
resolution defaults ever change in a different way.
At the point where they do change, we either do or don't want a way to support
the old 'fallback',
but we will want to support the new 'default'.
I think we should aim for forwards-compatibility as well as
backwards-compatibility, and that means being able to positively assert
that the current behaviour should continue for as long as the engine
supports it. If I add declare(function_and_const_lookup='default') at
the top of my file, I don't get that guarantee, because the meaning of
'default' might change.
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
That doesn't mean we have to support both modes forever - we can make
'fallback' mode immediately error, which is still useful feedback for
anyone who added it to their code.
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.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
