On Thu, Jul 16, 2020 at 9:29 PM Mark Randall <marand...@php.net> wrote: > > 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.
This is not quite the same. I said it moves from _userland_ aka PHP code, to an _extension_ aka C code. I oppose `Ext` in both case. > > 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. There is no need to separate between _extensions_ and _userland_ code. I believe this very premise is flawed. I don't care to debate it. I will just vote no. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
