Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124579
Message-ID: <927705b0404e70b0f0ade4a3354b2598d7c112f9.camel@ageofdream.com>
Subject: Re: [PHP-DEV] Should PHP reserve a namespace for built-in classes?
To: Tim =?ISO-8859-1?Q?D=FCsterhus?= <tim@bastelstu.be>, 
	internals@lists.php.net
Date: Wed, 24 Jul 2024 15:44:01 -0400
In-Reply-To: <95f6046a-4acf-4f8a-a850-a23650c0c6b3@bastelstu.be>
References: <76559a9cd5eca4bc6799ed9612ce15c28cd7cb0a.camel@ageofdream.com>
	 <95f6046a-4acf-4f8a-a850-a23650c0c6b3@bastelstu.be>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.4-2 
Precedence: bulk
MIME-Version: 1.0
From: lists@ageofdream.com (Nick Lockheart)

On Wed, 2024-07-24 at 19:51 +0200, Tim D=C3=BCsterhus wrote:
> Hi
>=20
> On 7/24/24 19:43, Nick Lockheart wrote:
> > What is the general feeling about reserving a namespace for PHP's
> > built
> > in classes?
>=20
> see https://wiki.php.net/rfc/namespaces_in_bundled_extensions
>=20
> Best regards
> Tim D=C3=BCsterhus


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.

The problem, as I see it, is that new names that come bundled with PHP
can be arbitrary. If new bundled classes can have arbitrary dictionary
words as the namespace, then we may actually have a bigger problem as
no name space is safe from future collisions.

The biggest problem with built-ins is that you can't unregister them.

I think a better solution would be to have one namespace for all
bundled classes, so that a specific namespace is reserved in advance.

From the RFC:

> 3rd-party extensions clearly cannot start out under a PHP namespace,
> as they have no direct relation to, endorsement by, or oversight of
> the PHP project. If all symbols in bundled extensions are to be
> prefixed by PHP, this would require a rename of all symbols when an
> extension moves from 3rd-party to bundled.

I think this is the real issue: How could we use a small number of
reserved namespaces for built-ins, but deal with permanence of those
names as things move around?

What if we had a grandfather policy?

Once a third party is accepted into core, it gets a core namespace.
If it is later removed from core, it gets grandfathered into being
allowed to use the core namespace, even if it is once again third
party.

The RFC did mention that once something moves to core, it seldom moves
back out, if ever.=20

There was a vote on something similar four years ago, 13(no)/17(yes),
declined. It was four votes shy of passing:

https://wiki.php.net/rfc/php_namespace_policy

There was more in that proposal though: the use of component namespaces
in addition to just `\php`.

Could this issue possibly be revisited and voted on with a more narrow
scope?

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.