Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109662
Return-Path: <ajf@ajf.me>
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 28743 invoked from network); 15 Apr 2020 18:43:50 -0000
Received: from unknown (HELO localhost.localdomain) (76.75.200.58)
  by pb1.pair.com with SMTP; 15 Apr 2020 18:43:50 -0000
To: internals@lists.php.net
References: <CANOvohpz5OzHZSxdABncBXRQfeF-XnKqpK8BBDQ8OeT+jBL96w@mail.gmail.com>
Date: Wed, 15 Apr 2020 19:13:48 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0)
 Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.2
MIME-Version: 1.0
In-Reply-To: <CANOvohpz5OzHZSxdABncBXRQfeF-XnKqpK8BBDQ8OeT+jBL96w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Posted-By: 46.59.72.204
Subject: Re: [RFC] PHP Namespace Policy
From: ajf@ajf.me (Andrea Faulds)
Message-ID: <php.internals-109662@news.php.net>

Hi Mark,

Mark Randall wrote:
> As internals "claims" the top level namespace, this effectively means
> that all userland code must exist in its own namespace, which is
> indeed how almost all modern userland code is written, which if
> anything this proves the benefit of namespacing.

Yes, post-5.3 PHP internals has essentially claimed the \ namespace for 
itself by inaction. Is that a bad thing? It makes all new internal 
functions and classes easy to access.

> In effect, this is both demanding a particular style, while choosing
> not to use it ourselves.

Sure, but your proposal would have us essentially be inconsistent about 
using namespaces, as 99% of internal functions, classes and constants 
would still be un-namespaced.

> Furthermore, based on the common understanding that a namespace owns
> and is responsible for all of its descendants, our current arrangement
> is that _all_ code belongs to PHP and that internals using _any_
> namespaces at all could lead to a legitimate collision.

This feels like reaching to me. Yes, there is an established convention 
for namespaces in userland, but as you already acknowledged, internals 
isn't following that convention. I don't think anyone who has some 
familiarity with PHP would notice all internals stuff is in \ and 
conclude that PHP 8.2 is going to add classes beginning with \Symfony\ 
or something — after all, wouldn't that mean *all* projects with a 
history predating PHP 5.3 also own all namespaces?

I think this proposal would create more inconsistency (99% of classes in 
\, some classes in \PHP\) for negligible benefit.

Regards,
Andrea