Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109647
Date: Wed, 15 Apr 2020 12:23:36 +0100 (BST)
To: Mark Randall <markyr@gmail.com>
cc: internals@lists.php.net
In-Reply-To: <CANOvohpz5OzHZSxdABncBXRQfeF-XnKqpK8BBDQ8OeT+jBL96w@mail.gmail.com>
Message-ID: <alpine.DEB.2.21.2004151222190.3610@singlemalt.home.derickrethans.nl>
References: <CANOvohpz5OzHZSxdABncBXRQfeF-XnKqpK8BBDQ8OeT+jBL96w@mail.gmail.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Subject: Re: [PHP-DEV] [RFC] PHP Namespace Policy
From: derick@php.net (Derick Rethans)

Hi Mark,

On Wed, 15 Apr 2020, Mark Randall wrote:

> I would like to re-open the discussion on properly reserving the \PHP
> namespace for the use of the engine and its core extensions.

I will be voting no against this. The RFC states:

    By design this RFC does NOT propose moving anything existing into
    the \PHP namespace at this time, only that the policy is set that it
    is the preferred mechanism for future development.

This will mean that in a future version of PHP, some things will live in
a \PHP namespace, and others, such as DateTimeImmutable or Directory do
not. We should not be introducing inconsistencies.

It also says:

     \PHP (must be empty except for other namespaces)

Which means new additions to PHP 8, such as a potential PhpAttribute,
now would have been \PHP\Engine\Attribute, while we already have
PhpToken. That is another inconsistency that we don't need.

I would potentially be OK with having both \PHP\Token and
\PHP\Attribute, as in PHP 8 these engine related classes are being
introduced for a first time (as far as I am aware).

cheers,
Derick

-- 
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug