Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109649 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 76395 invoked from network); 15 Apr 2020 13:13:46 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 15 Apr 2020 13:13:46 -0000 To: internals@lists.php.net References: Date: Wed, 15 Apr 2020 12:43:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Posted-By: 87.81.129.66 Subject: Re: [PHP-DEV] [RFC] PHP Namespace Policy From: marandall@php.net (Mark Randall) Message-ID: On 15/04/2020 12:23, Derick Rethans wrote: > 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 notes that it should be the preferred method for new feature development, and intentionally stops short of requiring it, to provide plenty of room for leeway in cases like this where there is an obvious benefit to keeping features aligned. > 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 argue that both these two great new features would benefit from an additional level, unless of course we can guarentee that we would never introduce anything else into PHP called token, or attribute, at which point we are back to square one, a problem which can be almost all together avoided by adding a "feature" specific namespace under \PHP. -- Mark Randall marandall@php.net