Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108313
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>
 <CALKiJKrkuc5d5k6oS9LK=m3pDA3zrbU2C+7py_maU0Bpq9JF7w@mail.gmail.com> <DM5PR07MB3067CC8A8DE6C4D4E0B45B99F9050@DM5PR07MB3067.namprd07.prod.outlook.com>
In-Reply-To: <DM5PR07MB3067CC8A8DE6C4D4E0B45B99F9050@DM5PR07MB3067.namprd07.prod.outlook.com>
Date: Wed, 29 Jan 2020 09:57:34 +0000
Message-ID: <CALKiJKrwHx8fcZpm79uS6TyZasOfPJ4CkOuDb+johYmChr85NA@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000004cc460059d445f5c"
Subject: Re: [PHP-DEV] [RFC] "use global functions/consts" statement
From: rowan.collins@gmail.com (Rowan Tommins)

--0000000000004cc460059d445f5c
Content-Type: text/plain; charset="UTF-8"

On Wed, 29 Jan 2020 at 01:23, tyson andre <tysonandre775@hotmail.com> wrote:

> If a future language change changed the *default* resolution rules for
> functions or constants,
> I'd rather have future maintainers make the decision on whether to add a
> 'fallback' to make migration
> than on whether to remove the 'fallback' if it didn't make sense to
> support it.
>
> We have different values and expectations on what's likely to happen in
> the future of the language.
>



I think it's more that we have different understandings of what exists in
the language *right now*.

In my mind, strict_types has two modes, called 0 and 1; both have fully
documented behaviour, and changing either one of them would be a breaking
change. At the top of a file, I can specify which of those two modes I want
the code to run in. As a convenience, if I don't specify, the code will run
in mode 0 - but that doesn't have any implications for what mode 0 means.


Similarly, if this RFC is merged, we will have two algorithms for resolving
a function name in a namespace; let's call them mode A and mode B.

* Mode A is "namespace first, fallback to global". It was first defined in
PHP 5.3, and as far as I know hasn't changed since. We don't have to be
speculate on how that mode works, we've been writing code in that mode for
10+ years.
* Mode B is "global only", and is new in this RFC.

In the same way I can specify the strict_types mode, I want to be able to
specify at the top of a file whether it should run in mode A or mode B. If
I don't specify, it makes sense to assume mode A, but that's just a
convenience; it could theoretically give an error telling me to confirm
which mode I want.

Of course things might change in future:

* Someone might add mode C, in which case I can select that for files where
I want to use it.
* The default mode might change from A to C. All my existing code is
written to use mode A, so I want to make sure it continues to run in mode A
until I've updated it.
* We might deprecate and remove mode A, in which case I'll get log messages
for the files where I've specified mode A, telling me to change my code to
run in mode B or C.

In all of those scenarios, it's an advantage to be able to declare mode A.
In none of those scenarios do I get any advantage by specifying "use
default mode".




> > 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?
>
> The use cases are similar to the reasons why I'd want to use
> strict_types=0.
> strict_types=0 is rare in practice.
>
> 1. Explicitly writing in code that you have chosen on a setting for the
> file
>    and decided not to use 'global'.
> 2. Overriding the namespace default if
> https://wiki.php.net/rfc/namespace_scoped_declares
>    gets accepted.
>



The reason I asked for specific examples is because every single scenario
I've thought of so far, whether it's future changes to the language or
namespace-scoped declares, would work better with an explicit mode setting,
not a 'default' option.

For instance, over-riding the namespace default sounds like a plausible use
for 'default', but in practice, you wouldn't care which mode was the
default for PHP; you would know that this particular file will only run
correctly in mode A. So you would specify mode A at the top of the file,
not 'default'.

I have genuinely tried to come up with a situation where 'default' would be
useful, and I have failed.



Regards,
-- 
Rowan Tommins
[IMSoP]

--0000000000004cc460059d445f5c--