Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107888
To: internals@lists.php.net
References: <DM6PR07MB45536166C2939FF19F496893F9440@DM6PR07MB4553.namprd07.prod.outlook.com>
 <CAEPJdukU6x5QpD22_9jkMRrQpOwuwybp6n2gwNgnBi1geMoLGA@mail.gmail.com>
 <DM6PR07MB4553BA2656E6CA742448C58BF9470@DM6PR07MB4553.namprd07.prod.outlook.com>
Message-ID: <e17f2c0a-8a95-1501-a7ac-7dae0f41b814@gmail.com>
Date: Thu, 28 Nov 2019 21:24:12 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <DM6PR07MB4553BA2656E6CA742448C58BF9470@DM6PR07MB4553.namprd07.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] Re: Opt-in "use function *;" for skipping check for
 function/const in alternate namespace
From: rowan.collins@gmail.com (Rowan Tommins)

On 28/11/2019 18:52, tyson andre wrote:
>> An opt-in mechanism is certainly easier to migrate to, but it would be a
>> shame if every PHP file in 10 years time included a line like this:
>>
>> use function *; // don't know what this does,
>> but apparently it's good for performance ¯\_(ツ)_/¯
> I'm not sure what assumptions you're making about php in 10 years
> (e.g. do you assume the other RFC will pass and this would become a no-op)


My assumptions weren't particularly about the future of PHP, but about 
people's usage patterns. If nobody uses namespaced functions, then 
everyone will just turn on this option all the time, without ever 
needing to know what it does. The effect of adding it to 99% of PHP 
files would be nothing but a "magical" performance boost.


> if someone were to fully qualify all function calls for a library for performance,
> there'd be around 10 lines per file instead of 1

Only if they did it by adding use statements, rather than prefixing the 
function calls with backslashes. I'm confused why anyone would bother 
keeping a long list of use statements up to date, rather than just 
making "use leading backslashes on global functions" part of the 
project's coding style. I can see that adding a single statement to each 
file would be better than either, though.


> My reasons for this syntax instead of that are:
>
> - This syntax can go in one block of code, instead of separated by dozens of lines:
>
>    <?php declare(strict_types=1);
>    // dozens of lines of class uses, file comments, etc.
>    use function otherns\my_function;
>    use function *;
> - There are no per-namespace declare() directives right now, for code with multiple namespace blocks

I think it's more than just a different choice of syntax, it's a 
different way of looking at the feature: rather than a special namespace 
import, it's an option for how the language behaves. My thinking is that 
if unprefixed functions *always* referred to the global namespace, we 
wouldn't say "the global namespace is imported by default", we'd just 
describe the behaviour.

Looked at from that perspective, it seems natural to say "in this file, 
I want the behaviour where unprefixed functions mean global by default"; 
and in future, maybe be able to say "in this entire module, I want that 
behaviour".


A more cosmetic consideration is that the more generic the syntax looks, 
the more people will want it to work for other use cases. I can imagine 
"use function * works but use Foo\* doesn't" ending up on websites like 
PHPSadness. A more specific statement, like a declare, or "use global 
functions", is more obviously a one-off.

Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]