Re: [RFC] \PHP namespace usage heuristics

On Thu, Jul 16, 2020 at 3:42 PM Larry Garfield <larry@garfieldtech.com> wrote: > > After some discussion, the namespacing proposal has been again updated. Two major changes: > > 1) Only engine code goes in \PHP. There's a separate \Ext namespace for extensions, > whether bundled or PECL. > > 2) It establishes that an index will be maintained on the Wiki listing what namespaces are > already claimed. > > https://wiki.php.net/rfc/php_namespace_policy > > This is probably (I hope) the final edit of consequence before voting. Speak now or forever > hold your peace. :-) Chiming in to formally oppose \Ext. I don't think it holds much value for a few reasons: 1. If all extensions are in the same namespace then they have to work out conflicts between themselves anyway. This would not have helped mongo and mongodb, for instance, nor memcache and memcached. 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. - It's more typing for... what gain, exactly? 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.