Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99481
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.196 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <3515b508-4571-0d57-6b47-616cae0b0908@fleshgrinder.com>
References: <990f6d85-e3ed-05a4-42e0-d3a279c0ebe7@fleshgrinder.com>
 <277f53cd-0e79-6fcc-fa4b-b0527ca525b6@fleshgrinder.com> <CAFMT4Nr1Git3u6oEBpZe4W3e68MnrOr6_bwAsRTzDtS2Y=Hbmg@mail.gmail.com>
 <3515b508-4571-0d57-6b47-616cae0b0908@fleshgrinder.com>
Date: Sat, 10 Jun 2017 13:24:43 -0600
Message-ID: <CAFMT4NqaoC5==tRsy_r1f7tqnAf_sTTrHyrUZqMt2cW11M1HdA@mail.gmail.com>
To: Fleshgrinder <php@fleshgrinder.com>
Cc: php-internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Namespaces in Core
From: levim@php.net (Levi Morrison)

On Sat, Jun 10, 2017 at 1:13 PM, Fleshgrinder <php@fleshgrinder.com> wrote:
> On 6/10/2017 8:54 PM, Levi Morrison wrote:
>> I gave this feedback before but I'll repeat it. I support namespaces
>> in the core, with the `PHP` namespace (with whatever capitalization we
>> decide) to be reserved *solely* for things related to the language
>> itself such as lexer, parser, etc.
>>
>> I am fine with other extensions using namespaces but should use
>> appropriately named ones. Using the `PHP` namespace to indicate
>> something is packaged in core is a poor decision. We have moved
>> existing extensions into core and it would not make sense to rename it
>> simply because it was moved into core because it's a backwards
>> compatibility break. Similarly we've moved at least one extension out
>> of core and it doesn't make sense for it to have the `PHP` name when
>> it's not in core, but renaming it is yet other backwards compatibility
>> break. It's simply not prudent. Instead extensions should be named
>> after what they are, the vendor they are for, or some other name; this
>> is the same process user-land packages go through and core should not
>> be different.
>>
>
> Thanks for that, much appreciated.
>
> This is exactly what I am proposing. Only things that are provided
> directly from the PHP Group should go into the PHP namespace. Any- and
> everything else should go into appropriate vendor namespaces.
>
> I think that you are considering e.g. array functions as not being part
> of PHP, and that you want to put them in a separate namespace. So
> effectively we would have something like:
>
>     PHP\Lexer
>     Arrays\Array
>     IO\File
>     Logging\Logger
>     Reflection\Reflector
>     Strings\String
>     UUIDs\UUID
>
> I personally do not like this approach. PHP is the vendor of these
> things, thus, it should reside in the namespace of the vendor. Same
> rules for everyone. IO for instance is not a vendor, it is a particular
> use-case (working with files) and thus should not go directly into the
> global namespace.
>
> There is imho no reason to move `PHP\Reflection\Reflector` to
> `Reflection\Reflector` just because we decided, for whatever reason, to
> remove reflection from core and instead providing it via PECL. PHP would
> still be the vendor of it.
>
> The misconception that I am seeing is, that the PHP namespace is bound
> to PHP, which it isn't: it is the vendor namespace of the PHP Group.
>
> The PHP community at large has settled with this approach, and I believe
> that it is a very good approach. It effectively avoids namespace
> collisions and helps to identify the vendor of a particular implementation.
>
> Would love to hear what others think about this.
>
> --
> Richard "Fleshgrinder" Fussenegger
>

If we were starting from scratch maybe we'd do as you are proposing.
However, there is absolutely zero value in these specific things being
namespaced *anywhere*:

  - Arrays
  - Reflection
  - Strings
  - IO

We already have established conventions and prefixes around these.
Moving them to a namespace has zero value.

I'm not sure what logging you are talking about for PHP.

That leaves UUID, which I am fine with having its own namespace if
there are enough functions, constants, classes, etc to support it.