Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108295
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>
In-Reply-To: <DM5PR07MB3067449706E551BC9DE8D02EF90A0@DM5PR07MB3067.namprd07.prod.outlook.com>
Date: Tue, 28 Jan 2020 17:08:26 +0000
Message-ID: <CALKiJKpiPD54b+6vP+0iWCUdrBbxaSdE-_hnq0vAyHAmKznhpQ@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000005ede05059d364602"
Subject: Re: [PHP-DEV] [RFC] "use global functions/consts" statement
From: rowan.collins@gmail.com (Rowan Tommins)

--0000000000005ede05059d364602
Content-Type: text/plain; charset="UTF-8"

On Tue, 28 Jan 2020 at 15:42, tyson andre <tysonandre775@hotmail.com> wrote:

> > 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
> argument
> over whether there should be a `strict_types='off'` vs `='default'`
> and `strict_types='on'`
>



I have always read 0 and 1 as meaning 'off' and 'on' in that context; the
idea that 0 could mean "whatever the current PHP default is" is completely
new to me. (I actually find it slightly unidiomatic for PHP to use a number
rather than a string there.)




> - Confusion by new developers over whether `'fallback'` is weaker than
> omitting the option.
>



What do you mean by "weaker"?

A value of "fallback" would mean "I expect function calls in this file to
refer to the same namespace if possible, and fall back to the global
namespace"; no more, and no less. That feels like a well-defined and useful
assertion.

A value of "default" would presumably mean "I have no expectations about
what function calls in this file should refer to, and am happy for PHP to
arbitrarily change their meaning in future in undefined ways". Why would
anyone want to assert that?




>   (e.g. if `count()` uses a keyword that's always the global function,
> like `empty()` currently does, as an unrealistic/undesirable example)
>
...

> 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=0 to be required to allow it.
>



Let's flip those examples around: what if we want to make some magic
function always resolve to the current NS even in
function_and_const_lookup='global' mode, or a particular cast be allowed
even in strict_types=1 mode? The two different modes for strict_types
aren't even "old" and "new", they were both added at the same time, so
there's no reason one should have a stronger BC guarantee than the other.

Calling the mode 'default' won't stop people's code breaking if we change
the resolution rules, and won't mean we can just ignore breaking changes,
any more than if we hadn't added the mode switch in the first place. All it
means is that if we change the default *mode*, it's unnecessarily difficult
for people to migrate (see previous example scenarios).



My worst fear is that we add this mode labelled as 'default', but actually
tie it to the current behaviour, so that we eventually have a mode called
'default' that isn't the default. This happened to Wikipedia: they named
their default skin 'standard', then regretted it when they changed the
default to be something else.



Regards,
-- 
Rowan Tommins
[IMSoP]

--0000000000005ede05059d364602--