Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108278
To: internals@lists.php.net
References: <DM5PR07MB3067B7578E3F04C5A20A221AF9210@DM5PR07MB3067.namprd07.prod.outlook.com>
 <DM5PR07MB3067A4F37F4D8E6738582859F9300@DM5PR07MB3067.namprd07.prod.outlook.com>
 <b8e7ced4-9cec-4bde-a009-622c477a0e58@DB3EUR04FT030.eop-eur04.prod.protection.outlook.com>
 <DM5PR07MB306711A0E8F1CADB23C17CB5F9300@DM5PR07MB3067.namprd07.prod.outlook.com>
 <CAF+90c-Rmmh3+iYqFmn1E+W5-S1qT4BpPhN9wgroz=9ZudeWpg@mail.gmail.com>
 <CAOWwgpkmawRgSJ2J8ZMoh_0MBskOgwJu-=HGJ42=6EQt+vz0Gw@mail.gmail.com>
 <DM5PR07MB30671C0F3103E927A1532B6CF90E0@DM5PR07MB3067.namprd07.prod.outlook.com>
 <CAF+90c8uCL85dVbLgapV2gOypFNBqocqvYWDB=JHKEmrq2JCwA@mail.gmail.com>
 <DM5PR07MB30677F5577E4C2105DF7B68EF9080@DM5PR07MB3067.namprd07.prod.outlook.com>
 <A5AD5FD1-7CA1-49D9-86A0-D72EA08A84F5@gmail.com>
 <DM5PR07MB3067F716C9F0E6D5C2DB3D9DF9080@DM5PR07MB3067.namprd07.prod.outlook.com>
 <CAF+90c8sBcWnsZxMQNgOccHeVbDnhHmjbbRuCzO8QD9oJZA6jA@mail.gmail.com>
 <DM5PR07MB30675BDFD91C54AAF45E9261F90B0@DM5PR07MB3067.namprd07.prod.outlook.com>
Message-ID: <dace510b-46c0-8b06-ca8b-5159f90af1a6@gmail.com>
Date: Mon, 27 Jan 2020 19:49:52 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <DM5PR07MB30675BDFD91C54AAF45E9261F90B0@DM5PR07MB3067.namprd07.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] [RFC] "use global functions/consts" statement
From: rowan.collins@gmail.com (Rowan Tommins)

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]