Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108299
MIME-Version: 1.0
References: <DM5PR07MB3067B7578E3F04C5A20A221AF9210@DM5PR07MB3067.namprd07.prod.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>
 <dace510b-46c0-8b06-ca8b-5159f90af1a6@gmail.com> <DM5PR07MB3067ACE4E99E69B276DD8E5CF90A0@DM5PR07MB3067.namprd07.prod.outlook.com>
 <2d50c8c0-cbd1-0a0e-4098-eb00facf86db@gmail.com> <DM5PR07MB3067449706E551BC9DE8D02EF90A0@DM5PR07MB3067.namprd07.prod.outlook.com>
 <CALKiJKpiPD54b+6vP+0iWCUdrBbxaSdE-_hnq0vAyHAmKznhpQ@mail.gmail.com> <DM5PR07MB3067331CFA744D19BDCF01E9F90A0@DM5PR07MB3067.namprd07.prod.outlook.com>
In-Reply-To: <DM5PR07MB3067331CFA744D19BDCF01E9F90A0@DM5PR07MB3067.namprd07.prod.outlook.com>
Date: Tue, 28 Jan 2020 18:51:46 +0000
Message-ID: <CALKiJKrkuc5d5k6oS9LK=m3pDA3zrbU2C+7py_maU0Bpq9JF7w@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e2f488059d37b79f"
Subject: Re: [PHP-DEV] [RFC] "use global functions/consts" statement
From: rowan.collins@gmail.com (Rowan Tommins)

--000000000000e2f488059d37b79f
Content-Type: text/plain; charset="UTF-8"

On Tue, 28 Jan 2020 at 18:13, tyson andre <tysonandre775@hotmail.com> wrote:

> That's more of an objection to 'global' than an argument about 'fallback'
> or 'default'.
> It isn't suggesting a name to use instead of 'global'.
>


No, it's saying that whatever name you use, the guarantees of behaviour are
only as strong or weak as decisions we make in the future about Backwards
Compatibility. That's no more or less true for one mode than the other,
regardless of what we call them.



> Any changes I don't expect to strict_types or function_and_const_lookup
> would be discussed in the RFCs proposing those changes.
>


Yes, and that includes changes to how 'fallback' mode works.



> For allowing a particular cast with strict_types=1,
> only strict_types=1 would probably need to be changed to keep backwards
> compatibility,
> since code without TypeErrors would continue to work.
>



OK, bad example; what if we make the rules around int->float coercion
stricter? The point is, why is a breaking change to mode 1 fundamentally
different from a breaking change to mode 0?



If 'fallback' and 'default' ever mean different things,
> we'll very likely need to add 'default' again if namespace-scoped declares
> become a thing.
>



I still don't understand why you would ever want that. Perhaps it would
help to think about specific examples:

When I write file foo.php, I know that I want to use functions in the
current namespace if they are defined. So I add
declare(function_and_const_lookup='fallback') to that file to make sure it
continues to work:

* If the PHP default changes to 'global', the file setting will tell it to
use 'fallback' mode instead
* If a namespace-scoped declare is set to 'global', the file setting will
take precedence, so it will still use 'fallback' mode

Similarly, when I write file bar.php, I add
declare(function_and_const_lookup='global'); no matter what the PHP default
or namespace-scoped setting say, the file will act as I intended.

Can you provide an example of when you'd want to use 'default' instead of
specifying the mode you've written the file to run in?




> A 'fallback' can be added if and when we have a use case for it.
>


I'm saying we do have a use case: enabling forwards compatibility so that
we can change the default in future if we want to.

I'm still trying to understand the use case for 'default', though.




> There are large numbers of settings with values of 'standard'/'default'
> that became problems.
> There are large numbers of settings with values of 'standard'/'default'
> that made perfect sense
> and didn't cause any issues.
>


Sure, and I gave a rule of thumb for that earlier: "default" makes sense
when the setting *doesn't actually matter*, and you want to delegate the
decision. That doesn't seem to apply to this case.


Regards,
-- 
Rowan Tommins
[IMSoP]

--000000000000e2f488059d37b79f--