Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:107956 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 21487 invoked from network); 2 Jan 2020 06:28:00 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 2 Jan 2020 06:28:00 -0000 To: internals@lists.php.net References: Date: Thu, 2 Jan 2020 04:31:48 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Posted-By: 90.219.4.98 Subject: Re: [RFC] "use global functions/consts" statement From: marandall@php.net (Mark Randall) Message-ID: On 01/01/2020 19:31, tyson andre wrote: > This RFC proposes to support an opt-in "use global functions/consts;" statement to disable PHP's check for the function/const in the current namespace before falling back to the global namespace. It's an interesting idea, but at this time I think it's the wrong approach to what is in the best long-term interests of the language by introducing an additional point of inconsistency. Classes search the current namespace, but functions / const would search namespace first, unless they don't, then global? For the very minor one-time performance hit (thanks to the cache slot), I think the situation is best remaining as-is for the time being. In future, I think the optimal solution is opt-in deprecating fallback to the root namespace using a declare. We might eventually benefit from versioned "libraries" of functions that can be imported in one command which would solve many-a-future-problem by itself. Somewhat related is how global functions are consumed - Id like to see nikic/scalar_objects added to the core in 8.0, that would offer non-procedural (and therefore non-namespaced) access to many of the most common global functions (strings, arrays etc). In turn, that would allow developers to limit the number of use \... statements. That doesn't cover defined constants, but IMO we should be pushing those to be moved into class constants, simply because in the absense of function / constant / anything-but-class level autoloading, things might as well be in a readily available location. -- Mark Randall marandall@php.net