Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108291
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:
 AQHV1IfBuqjWnIu9lEWrxlRKvYFij6f9dXecgADKhQCAAFMdqIAAWbgAgABUv12AAInJAIAAbhnX
Date: Tue, 28 Jan 2020 15:42:37 +0000
Message-ID:
 <DM5PR07MB3067449706E551BC9DE8D02EF90A0@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>
In-Reply-To: <2d50c8c0-cbd1-0a0e-4098-eb00facf86db@gmail.com>
Accept-Language: en-CA, en-US
Content-Language: en-CA
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [lEO46QqutRCRr+V49V+Zb+KCGnUbZ/h6]
x-ms-publictraffictype: Email
x-incomingheadercount: 45
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 9cd0b327-c2f6-4bfc-0531-08d7a408b38f
x-ms-traffictypediagnostic: DM6NAM11HT232:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 glFLU8puZJOb9QzhOtliLpY7rbLwbbLROO3qLy6oO/HDZlSexL8QJCfiyzN/VJBhwbKdJIL73cKW87BvK7pbeVPI7NqnM9xW/ZTCU8DnGU2DHi1SVEzv+8NWWBjAW2UFuwQuDVZteCYwr2NsdZuWNkFFRYmiwgP9hkAoS5LQtcZcegAcKaDHYRm5fjQbQnOnbN0FrDLSFtqoTrfXTg7ABK0FUi8VDp+HfiQhsPFYSaQ=
x-ms-exchange-antispam-messagedata:
 DWQuufvT7+yE1dUUDs6piWKxtUCy04bG45jmrMP9bukZun5ZbvWZpDAzMhWfpe8yYuyMlYy/BoKOjKQxYfk4VEn+Mb8BhS4Gkp9iMJHINJZDAdTKkOakGrHV264L1Z6+PB6ujOmCbNN8CQnMsZyMFQ==
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: 9cd0b327-c2f6-4bfc-0531-08d7a408b38f
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2020 15:42:37.4103
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6NAM11HT232
Subject: Re: [PHP-DEV] [RFC] "use global functions/consts" statement
From: tysonandre775@hotmail.com (tyson andre)

> I still don't understand this logic. If my code is written so that it
> needs the current "same namespace fallback to global" behaviour, I don't
> care what the default mode is, or how many other modes there are, I want
> to make sure that file will continue to use that mode. The *only* way to
> do that is if there is a directive saying *explicitly* that I want that
> mode.
>
> In other words, we don't need to know what the future modes are to know
what modes we have *right now*, and give those modes names.

If strict_types had a name instead of a number, we'd have a similar argumen=
t
over whether there should be a `strict_types=3D'off'` vs `=3D'default'`
and `strict_types=3D'on'`

`'default'` is the option I'd consider the best for what I consider to be
likely ways php will/won't change. I can

> I'm not seeing the downside of adding it now.

- Confusion by new developers over whether `'fallback'` is weaker than omit=
ting the option.
- Obliging future maintainers to potentially support whatever `'fallback'` =
would be understood to be
  if PHP's name resolution changes in a minor way.
  (e.g. if `count()` uses a keyword that's always the global function, like=
 `empty()` currently does, as an unrealistic/undesirable example)

> The difference is that we could change the default in a future version
> to be strict_types=3D1, and people could run code with strict_types=3D0 o=
n
> both versions with exactly the same effects. That's not the same as
> saying strict_types=3D'default'.

If php changes the default casting behavior to forbid weak casting boolean =
to string
or string to boolean (as another unrealistic example), I personally wouldn'=
t expect strict_types=3D0 to be required to allow it.
In that case, both versions wouldn't have the same effects.
Discussions on such a change may reasonably differ in those expectations.

> > I doubt that there would be an argument for creating `strict_types=3D'p=
hp7'` before we knew what those changes are,
>
> We already have created that: strict_types=3D0 and strict_types=3D1 can
> retain their current meaning, and any new mode can have a new name
> (strict_types=3D2, strict_types=3D'php9', whatever).
>
>
> To be clear, I'm not suggesting 'fallback' is added as a third option,
> I'm saying we should name the two options 'fallback' and 'global', just
> like strict_types has two options, 0 and 1. I can't think of any
> situation where I would want a change to the default mode in the engine
> to cause my code to be interpreted in a different way, so a 'default'
> option makes no sense to me.

I have a better understanding of why you're asking for this now,
but still prefer 'default' and 'global' for the reasons I've mentioned.

________________________________________
From: Rowan Tommins <rowan.collins@gmail.com>
Sent: January 28, 2020 4:06 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] "use global functions/consts" statement

On 28/01/2020 01:06, tyson andre wrote:
> I don't plan to change the default name resolution behavior in PHP 9, tho=
ugh,
> 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 still don't understand this logic. If my code is written so that it
needs the current "same namespace fallback to global" behaviour, I don't
care what the default mode is, or how many other modes there are, I want
to make sure that file will continue to use that mode. The *only* way to
do that is if there is a directive saying *explicitly* that I want that
mode.

In other words, we don't need to know what the future modes are to know
what modes we have *right now*, and give those modes names.


> I'd imagine the migration to 8.0 and 9.0 would be similar to 5.6 to 7.0


That's not the point; people want to be able to run the same code on
multiple versions; the sooner we include a forwards-compatible option,
the more versions code referencing that option can run on. I'm not
seeing the downside of adding it now.


> I see `strict_types=3D0` as similar - The value `0` is currently rarely u=
sed compared to leaving out the setting.
> If php 8.x were to become stricter about type casting by default in a few=
 ways,


The difference is that we could change the default in a future version
to be strict_types=3D1, and people could run code with strict_types=3D0 on
both versions with exactly the same effects. That's not the same as
saying strict_types=3D'default'.


> I doubt that there would be an argument for creating `strict_types=3D'php=
7'` before we knew what those changes are,


We already have created that: strict_types=3D0 and strict_types=3D1 can
retain their current meaning, and any new mode can have a new name
(strict_types=3D2, strict_types=3D'php9', whatever).


To be clear, I'm not suggesting 'fallback' is added as a third option,
I'm saying we should name the two options 'fallback' and 'global', just
like strict_types has two options, 0 and 1. I can't think of any
situation where I would want a change to the default mode in the engine
to cause my code to be interpreted in a different way, so a 'default'
option makes no sense to me.


Regards,

--
Rowan Tommins (n=E9 Collins)
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php