Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124581
Message-ID: <86b7e340-6ca9-4b3c-af0a-a5c2d1ee68c3@bastelstu.be>
Date: Wed, 24 Jul 2024 22:02:57 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] Should PHP reserve a namespace for built-in classes?
To: Nick Lockheart <lists@ageofdream.com>, internals@lists.php.net
References: <76559a9cd5eca4bc6799ed9612ce15c28cd7cb0a.camel@ageofdream.com>
 <95f6046a-4acf-4f8a-a850-a23650c0c6b3@bastelstu.be>
 <927705b0404e70b0f0ade4a3354b2598d7c112f9.camel@ageofdream.com>
Content-Language: en-US
In-Reply-To: <927705b0404e70b0f0ade4a3354b2598d7c112f9.camel@ageofdream.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

On 7/24/24 21:44, Nick Lockheart wrote:
> Thank you. I've read through the RFC and see it was approved. Is it too
> late to comment on this? My concern is that placing things into new and
> arbitrary namespaces as per the RFC is just a different variation on
> the global name problem.

Commenting is of course possible, but any changes would require another RFC.

In any case, the RFC's policy has already been used in the design of the 
new randomness API added in PHP 8.2.

> I think a better solution would be to have one namespace for all
> bundled classes, so that a specific namespace is reserved in advance.

Needing to prefix everything by \PHP or something like this would 
provide for a terrible developer experience when using the standard library.

> There was a vote on something similar four years ago, 13(no)/17(yes),
> declined. It was four votes shy of passing:

This is false. That RFC required a 2/3 majority to pass.

> I think if we reserved `\php` and `\ext`, then there would be no need
> to have multi-level namespaces, like the prior RFC proposed. I think
> every standard class could just be `\spl\classname` without any naming
> conflicts between core classes. And that would also avoid future
> namespace collisions.

Not using sub-namespaces would require making the classnames overly 
specific, because there's some names that make sense in different 
domains. An example would be a `Client` or `Connection`.

Best regards
Tim Düsterhus