PDO subclass names

On Tue, Apr 23, 2024 at 11:26 AM Stephen Reay php-lists@koalephant.com
wrote:

Sent from my iPhone



Hi internals,

Recently I've been working on an RFC regarding object support for
BCMath. While working on that, I learned of the following RFC:
https://wiki.php.net/rfc/namespaces_in_bundled_extensions

If we follow this RFC, is it reasonable to place subclasses of PDO
under the namespace "PDO”?

e.g.

PdoMysql => PDO\Mysql
PdoPgsql => PDO\Pgsql
PdoSqlite => PDO\Sqlite
PdoOdbc => PDO\Odbc
PdoDblib => PDO\Dblib
PdoFirebird => PDO\Firebird

We'll probably get a BC Break if try to fix this after 8.4 is released,
so before it's released is last chance to fix this safely.

If Tim's RFC under discussion is passed, the namespace will be "Pdo"
instead of "PDO”.
https://wiki.php.net/rfc/class-naming-acronyms

I would appreciate hearing your opinions.

Regards,

Saki

Hi Saki,

Consider that adding a namespace does not/should not change the class
name. That is, MyClass once namespaced becomes MyNamespace\MyClass.
Ergo, PdoMysql becomes Pdo\PdoMysql. The class name should still
make sense and be a "strong name" (without conflict) once imported.

To state it more concretely, I believe it is normal and correct to
include 1-3 namespace components within the class name itself, in order
to create such a "strong name". As a more concrete example of this,
consider HttpClient, FtpClient and SoapClient. Far too often, we
see user libraries (incorrectly) namespace these as Http\Client,
Ftp\Client and Soap\Client (or similar) where the leaf name just
becomes Client. "Client", by itself is a meaningless moniker, but that
is all we see once the name is imported, notwithstanding importing
multiple of these clients in one file causes conflicts that now need to
be resolved with local aliases. In general, I believe aliasing to be an
anti-pattern that points to a failure to create strong names and thus
should be avoided by including some of the namespace portion in the
class name to make the class name more meaningful. Once imported, we do
not see the namespace portion within the body of the file any more;
HttpClient and FtpClient make much more sense by themselves, whether
or not they would otherwise conflict.

Kind regards,
Bilge

The code base I work in has 25 classes that are called "Line". They have
namespaces like App\Model\Invoice\Line, this is cumbersome to work with
so I would also prefer something like Pdo\PdoMysql, even if it's not
likely to conflict with a name such as Mysql.

I don't think it's appropriate to claim that a namespace like
MyLib\HTTP\Client is categorically "wrong".

The argument that "Client" is meaningless becomes pretty moot when you
realise that you can import a namespace and use it relatively, if you so
wish:

import MyLib\HTTP;

$a = new HTTP\Client(...);

I'm not claiming that any particular import pattern is more "correct" (and
I think it's a bad idea to suggest that other usage patterns are
"incorrect") but adding repetitive prefixes kind of defeats the purpose of
namespaces.

You may as well just go back to MyLib_HTTP_Client, and ignore that
namespaces exist.

In your own codebase you should do what works best for you. When it comes
to vendor classes I don't want to have to scroll through a list of 20
identical classes to find the one in the right namespace. It requires extra
development and review effort to figure out if the right class called
"Client" or "Factory" is used. For reference, I have 12 "Response", 12
"Client", 20 "Factory", and 20 "TestCase" classes in this project, of which
most are vendors.

Using partially imported namespaces and aliases causes inconsistencies that
makes it harder to find things. Nobody here is advocating for
MyLibHttpClient class names either. Even in an IDE like Intellij with a
project the size I'm working with it's hard to quickly get the right
classes, especially in legacy code where some classes live in the global
namespace.

The argument that "Client" is meaningless becomes pretty moot when you
realise that you can import a namespace and use it relatively, if
you so wish:

import MyLib\HTTP;

$a = new HTTP\Client(...);

Hi Stephen,

Granted, but I also believe the user can and should have the reasonable
expectation that they can work comfortably (without conflicts or
aliases) using leaf (class) names exclusively.

Kind regards,
Bilge