Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99479
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.177 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <277f53cd-0e79-6fcc-fa4b-b0527ca525b6@fleshgrinder.com>
References: <990f6d85-e3ed-05a4-42e0-d3a279c0ebe7@fleshgrinder.com> <277f53cd-0e79-6fcc-fa4b-b0527ca525b6@fleshgrinder.com>
Date: Sat, 10 Jun 2017 12:54:33 -0600
Message-ID: <CAFMT4Nr1Git3u6oEBpZe4W3e68MnrOr6_bwAsRTzDtS2Y=Hbmg@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 12:11 PM, Fleshgrinder <php@fleshgrinder.com> wrote:
> On 6/3/2017 6:40 PM, Fleshgrinder wrote:
>> Next promised RFC (and the last one for this weekend):
>>
>> https://wiki.php.net/rfc/namespaces-in-core
>>
>> I am unsure about whether we should avoid the usage of abbreviations for
>> things like language (lang), standard (std), and utility (util). I think
>> it is not necessary to write them out fully, but, well, ...?!?
>>
>
> Bump, would love some feedback on the RFC and the open issues. Otherwise
> this goes into voting and lots of complains pop up. It would be much
> more efficient to use the discussion time for that.
>
> --
> Richard "Fleshgrinder" Fussenegger
>

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.