Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108305
To: Rowan Tommins <rowan.collins@gmail.com>, "internals@lists.php.net"
	<internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] "use global functions/consts" statement
Thread-Index:
 AQHV1IfBuqjWnIu9lEWrxlRKvYFij6f9dXecgADKhQCAAFMdqIAAWbgAgABUv12AAInJAIAAbhnXgAAYmgCAABHelIAACwEAgABtAwg=
Date: Wed, 29 Jan 2020 01:23:49 +0000
Message-ID:
 <DM5PR07MB3067CC8A8DE6C4D4E0B45B99F9050@DM5PR07MB3067.namprd07.prod.outlook.com>
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>,<CALKiJKrkuc5d5k6oS9LK=m3pDA3zrbU2C+7py_maU0Bpq9JF7w@mail.gmail.com>
In-Reply-To:
 <CALKiJKrkuc5d5k6oS9LK=m3pDA3zrbU2C+7py_maU0Bpq9JF7w@mail.gmail.com>
Accept-Language: en-CA, en-US
Content-Language: en-CA
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [plGKrFUnflk3rdiN3NW5o9LkDMKmmg9I]
x-ms-publictraffictype: Email
x-incomingheadercount: 45
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 2a1dcdf2-575b-42de-d239-08d7a459e4c2
x-ms-traffictypediagnostic: SN1NAM04HT211:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 PzZLiEE/lveUnGkc92qv18YBZXbTnqMj5zRrI67WEtr40KdcxkLtbh4/fgLcyENvK9QybNHUFkzsjevBdVZsdcGlklDkThK5S3UrL7YN7sbm0QOuI29rvkzU+f9sFzF0WDw00QFZER/fncFuJ7LyPpa/ou89EIBCn/fOH/FELfezmJaPRtD5tfesDVfRTR6B68Qi7ZMnir5n1BiS0kzYxALpzGAX7tMNkzDZxeBJ+bQ=
x-ms-exchange-antispam-messagedata:
 P0puK0CZg73yvj54SnAYzib5gqxHZgilIcZTdvF48+h3MeDd8xJIkRVHaWr/6eYQQJdoYpmXfIr1IKCTbQAzu/c+GgBjpZd7fwTNsIWREDPrlJL1cqtrMatm0a4Woo1Uu9GcYyLrDZqL3fAC5ZMTvw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 2a1dcdf2-575b-42de-d239-08d7a459e4c2
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2020 01:23:49.2842
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM04HT211
Subject: Re: [PHP-DEV] [RFC] "use global functions/consts" statement
From: tysonandre775@hotmail.com (tyson andre)

> > That's more of an objection to 'global' than an argument about 'fallbac=
k'=0A=
> > or 'default'.=0A=
> > It isn't suggesting a name to use instead of 'global'.=0A=
> >=0A=
>=0A=
>=0A=
> No, it's saying that whatever name you use, the guarantees of behaviour a=
re=0A=
> only as strong or weak as decisions we make in the future about Backwards=
=0A=
> Compatibility. That's no more or less true for one mode than the other,=
=0A=
> regardless of what we call them.=0A=
>=0A=
> > Any changes I don't expect to strict_types or function_and_const_lookup=
=0A=
> > would be discussed in the RFCs proposing those changes.=0A=
> >=0A=
>=0A=
> Yes, and that includes changes to how 'fallback' mode works.=0A=
=0A=
I've decided against proposing 'fallback',=0A=
so I'm not planning to work out how a future 'fallback' would work.=0A=
=0A=
I don't have anything to add for what I want 'global' to mean.=0A=
=0A=
> For allowing a particular cast with strict_types=3D1,=0A=
> only strict_types=3D1 would probably need to be changed to keep backwards=
=0A=
> compatibility,=0A=
> since code without TypeErrors would continue to work.=0A=
>=0A=
=0A=
OK, bad example; what if we make the rules around int->float coercion=0A=
stricter? The point is, why is a breaking change to mode 1 fundamentally=0A=
different from a breaking change to mode 0?=0A=
=0A=
If 'fallback' and 'default' ever mean different things,=0A=
> we'll very likely need to add 'default' again if namespace-scoped declare=
s=0A=
> become a thing.=0A=
>=0A=
=0A=
> I still don't understand why you would ever want that. Perhaps it would=
=0A=
> help to think about specific examples:=0A=
=0A=
If a future language change changed the *default* resolution rules for func=
tions or constants,=0A=
I'd rather have future maintainers make the decision on whether to add a 'f=
allback' to make migration=0A=
than on whether to remove the 'fallback' if it didn't make sense to support=
 it.=0A=
=0A=
We have different values and expectations on what's likely to happen in the=
 future of the language.=0A=
=0A=
> Can you provide an example of when you'd want to use 'default' instead of=
=0A=
> specifying the mode you've written the file to run in?=0A=
>=0A=
> > There are large numbers of settings with values of 'standard'/'default'=
=0A=
> > that became problems.=0A=
> > There are large numbers of settings with values of 'standard'/'default'=
=0A=
> > that made perfect sense=0A=
> > and didn't cause any issues.=0A=
>=0A=
> Sure, and I gave a rule of thumb for that earlier: "default" makes sense=
=0A=
> when the setting *doesn't actually matter*, and you want to delegate the=
=0A=
> decision. That doesn't seem to apply to this case.=0A=
=0A=
The use cases are similar to the reasons why I'd want to use strict_types=
=3D0.=0A=
strict_types=3D0 is rare in practice.=0A=
=0A=
1. Explicitly writing in code that you have chosen on a setting for the fil=
e=0A=
   and decided not to use 'global'.=0A=
2. Overriding the namespace default if https://wiki.php.net/rfc/namespace_s=
coped_declares=0A=
   gets accepted.=0A=
=0A=
That rule of thumb isn't the possible reason for why someone would use the =
name "default".=0A=
=0A=
- Tyson=0A=