Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110861
User-Agent: Cyrus-JMAP/3.3.0-dev0-576-gfe2cd66-fm-20200629.001-gfe2cd668
Mime-Version: 1.0
Message-ID: <49fd7972-8cec-4207-99af-6c77c2328211@www.fastmail.com>
In-Reply-To: <0771c3ac-53ec-4a7f-a4e9-6ae3c9b1f1f6@www.fastmail.com>
References: <0771c3ac-53ec-4a7f-a4e9-6ae3c9b1f1f6@www.fastmail.com>
Date: Tue, 07 Jul 2020 09:46:35 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Jun 23, 2020, at 7:30 PM, Larry Garfield wrote:
> Greetings, Internalians.
> 
> There has been much talk of the \PHP namespace of late, including one 
> unsuccessful RFC.  In the discussion, the pushback broke down into two 
> main camps:
> 
> * We should never namespace anything ever.
> * We can namespace things but we need something more concrete than 
> "RFCs can namespace things if they feel like it."
> 
> I can't do much about the former, but the latter is a solvable problem. 
>  To that end, Mark Randall and I have put together a new RFC on the 
> topic, based on a fruitful discussion in Room 11 a few weeks ago to 
> brainstorm what actual guidelines should be for what goes where.
> 
> https://wiki.php.net/rfc/php_namespace_policy
> 
> This proposal provides guidance to short circuit future subjective 
> bikeshedding, while still leaving some wiggle room for case-by-case 
> evaluation as needed.  That makes it different from prior attempts that 
> did not provide clear guidance for future RFC authors.
> 
> The specific guidelines offered may or may not appeal to you; those are 
> open to discussion (within reason; we don't want to end up back in "do 
> whatever" land as we know that won't help), but the more important 
> point is that clear guidelines are provided.
> 
> Also of note, although it uses existing code to demonstrate where 
> classes *would* go under this plan it does not immediately move 
> anything.  Those are left for future RFCs that would have to stand or 
> fall on their own merit.  It also provides for a very long grace period 
> for any such transitions to minimize disruption.
> 
> The intent is to bring this proposal to a vote in time for 8.0's freeze 
> one way or another, even though it's unlikely to have any impact on 8.0 
> itself.  It's still a convenient deadline.
> 
> *dons flame retardant suit*
> 
> -- 
>   Larry Garfield
>   larry@garfieldtech.com

This has reached the 2 week mark, but there's not been much discussion.  Anyone else want to weigh in?

I want to give it a few more days and possibly revise it to include a Wiki page as suggested, but probably will bring it to a vote within the next week or so.