On Thu, Jul 16, 2020 at 3:42 PM Larry Garfield <la...@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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
