Re: Should PHP reserve a namespace for built-in classes?

From: Date: Wed, 24 Jul 2024 20:02:57 +0000
Subject: Re: Should PHP reserve a namespace for built-in classes?
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
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

Thread (10 messages)

« previous php.internals (#124581) next »