Re: [RFC] \PHP namespace usage heuristics
| From: | Mark Randall | Date: | Fri, 17 Jul 2020 03:28:50 +0000 |
| Subject: | Re: [RFC] \PHP namespace usage heuristics | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-111056@lists.php.net to get a copy of this message | ||
On 17/07/2020 02:58, Levi Morrison via internals wrote:
2. I don't think this is solving any problems, really:This is not what the RFC proposes. The point of \Ext is that there would be no need to rename them when moving in or out of core.- Code can move from PHP land to an extension and back again.Should the namespace change just because it moved one way or the other? I vote no.
I'm strongly in the "make namespace short and flat" camp. Deeply nested namespaces make more sense when you need to distinguish between projects within a company, for a contrived exampleHow flat would you want it to be? This RFC proposes 1 level before the name of the feature, either PHP or Ext depending on its location. The purpose of that one level is to avoid extensions trampling into multiple userspace naming areas. Mark RandallAmazon\WebServices\SDK. I can see there being multiple projects with Amazon, and I can see there being multiple WebServices projects. Removing a namespace segment doesn't make a lot of sense either, except for perhaps collapsing the first two toAWSbut this is just another point to my short and flat camp. This deeply nested company organization is not the territory we are in as a project, so we should keep it simple and keep our namespace short and simple.