Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111057
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>
 <CAAKU0ukwo+B=ESSoLuCOPfuH9uphcqM4mC2xvnD5Mb9NBBxZ8Q@mail.gmail.com> <5f111b07.1c69fb81.85d87.548dSMTPIN_ADDED_MISSING@mx.google.com>
In-Reply-To: <5f111b07.1c69fb81.85d87.548dSMTPIN_ADDED_MISSING@mx.google.com>
Reply-To: Levi Morrison <levi.morrison@datadoghq.com>
Date: Thu, 16 Jul 2020 21:49:48 -0600
Message-ID: <CAAKU0u=JchAhHWHc=cjdV+AL3A=g0S5C8CoBrX0c+vkFScMnHw@mail.gmail.com>
To: Mark Randall <marandall@php.net>
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 9:29 PM Mark Randall <marandall@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.