Re: Should PHP reserve a namespace for built-in classes?
| From: | Tim Düsterhus | 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 internals+get-124581@lists.php.net 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 reservedNot 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\phpand\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\classnamewithout any naming conflicts between core classes. And that would also avoid future namespace collisions.
Client or Connection.
Best regards
Tim Düsterhus