Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110711
User-Agent: Cyrus-JMAP/3.3.0-dev0-543-gda70334-fm-20200618.004-gda703345
Mime-Version: 1.0
Message-ID: <0771c3ac-53ec-4a7f-a4e9-6ae3c9b1f1f6@www.fastmail.com>
Date: Tue, 23 Jun 2020 19:30:02 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: [RFC] \PHP namespace usage heuristics
From: larry@garfieldtech.com ("Larry Garfield")

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