Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111056 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 61614 invoked from network); 17 Jul 2020 04:35:44 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 17 Jul 2020 04:35:44 -0000 To: internals@lists.php.net References: <0771c3ac-53ec-4a7f-a4e9-6ae3c9b1f1f6@www.fastmail.com> <49fd7972-8cec-4207-99af-6c77c2328211@www.fastmail.com> <02b8e816-1f75-48b4-9614-cec236f6bcec@www.fastmail.com> Date: Fri, 17 Jul 2020 04:28:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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: [PHP-DEV] [RFC] \PHP namespace usage heuristics From: marandall@php.net (Mark Randall) Message-ID: On 17/07/2020 02:58, Levi Morrison via internals wrote: > 2. I don't think this is solving any problems, really: > - 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. 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. > 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 example > `Amazon\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 to `AWS` but 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. How 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 Randall