Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111055
MIME-Version: 1.0
References: <0771c3ac-53ec-4a7f-a4e9-6ae3c9b1f1f6@www.fastmail.com>
 <49fd7972-8cec-4207-99af-6c77c2328211@www.fastmail.com> <CAF+90c-rkgOdJMo=NFi1PKAKg+r56R26EmMDotZKQf19+z2Htw@mail.gmail.com>
 <cmu-lmtpd-1317118-1594400773-0@sloti26t05> <02b8e816-1f75-48b4-9614-cec236f6bcec@www.fastmail.com>
In-Reply-To: <02b8e816-1f75-48b4-9614-cec236f6bcec@www.fastmail.com>
Reply-To: Levi Morrison <levi.morrison@datadoghq.com>
Date: Thu, 16 Jul 2020 19:58:27 -0600
Message-ID: <CAAKU0ukwo+B=ESSoLuCOPfuH9uphcqM4mC2xvnD5Mb9NBBxZ8Q@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
From: internals@lists.php.net ("Levi Morrison via internals")

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.