Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109815 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 41998 invoked from network); 23 Apr 2020 16:16:19 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 23 Apr 2020 16:16:19 -0000 To: internals@lists.php.net References: Date: Thu, 23 Apr 2020 15:48:15 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 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: 87.81.129.66 Subject: Re: [RFC] PHP Namespace Policy From: marandall@php.net (Mark Randall) Message-ID: On 15/04/2020 12:21, Mark Randall wrote: > https://wiki.php.net/rfc/php_namespace_policy Just an update in light of the two different RFCs. Having chatted with the other RFC authors in R11, rather than racing to see who can get their RFC to vote first, it seems like there's room for both. Vote 1 would be the other RFC which would be something along the lines of: "Mandate the use of \PHP for future internal tightly-bound components" If vote 1 were passed, the next vote would be on this RFC, and would cover policy on namespace usage and would be something like: "The \PHP namespace must remain empty, except for child namespaces". This would be to prevent the problem of colliding internals symbols throughout the rest of PHP's maintained lifespan (such as what if there was something else added to core called Token). Vote 3 would mandate only autoloadable classes / interfaces / traits etc etc were used, allowing userland polyfills (where sensible) to provide a route for users to begin using newer API functionality without an immediate upgrade. Votes 1 and 2 passing would put us on a pretty good course for long-term sanity. Vote 1 passing and 2 failing would result in part of the problem just being moved to \PHP and exposing us to symbol collision further down the line. If vote 1 failed, we would have to consider if this RFC would pass with its tigher constraints. The question is, how would we vote on extra uses for PHP. While the alternative RFC mandates its use for tightly coupled, I think it makes a lot of sense to add extra things to it, such as re-designed collections (borg Ds?) in \PHP\Collections in a similar fashion to: https://docs.microsoft.com/en-us/dotnet/api/system.collections?view=netframework-4.8 Mark Randall