Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124577
Message-ID: <76559a9cd5eca4bc6799ed9612ce15c28cd7cb0a.camel@ageofdream.com>
Subject: [PHP-DEV] Should PHP reserve a namespace for built-in classes?
To: internals@lists.php.net
Date: Wed, 24 Jul 2024 13:43:48 -0400
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)


What is the general feeling about reserving a namespace for PHP's built
in classes?

As the number of built-in classes grows over time, the chances of
naming collisions with user classes will grow.

When naming conflicts occur, they happen in an unexpected way, that
does not make it readily obvious that a name conflict has occurred.

That's because most projects use auto loaders, and the auto loader only
runs if a class is unregistered.

If a user creates a class called "Directory" and places it in the auto
load path, then tries to instantiate it, they will *not* receive any
error.

If the user then tries to call Directory::MyMethod(), they are told
that the method doesn't exist, even when they are staring at the class
definition. The user presumes that the auto loader has found and loaded
the class, because there isn't a "class not found" message.

If new built-in classes are added in the future using common dictionary
words as the name, there is a good chance of confusing breaks when the
PHP version is updated.

Now that namespaces are a thing in PHP, maybe we should take a page
from C++'s book and have users include the standard library classes
they want, when they need them.

ie:

use \spl\Directory;

I'm also wondering if there would be any performance benefit to not
having a bunch of internal classes pre-registered "just in case".