Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123173
Precedence: bulk
MIME-Version: 1.0
References: <6923C7CF-9168-433C-B2B3-9069F1A766B8@sakiot.com> <512bd0ff-4428-4028-8c59-7fb3f8f01621@scriptfusion.com>
In-Reply-To: <512bd0ff-4428-4028-8c59-7fb3f8f01621@scriptfusion.com>
Date: Tue, 23 Apr 2024 10:36:20 +0200
Message-ID: <CANS-=pfcqB5=dw45gwPjor6-9z-bG3Kv+sYwDgLbbRx8avOQcQ@mail.gmail.com>
Subject: Re: [PHP-DEV] PDO subclass names
To: Bilge <bilge@scriptfusion.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="00000000000066baa00616bf746f"
From: kjarli@gmail.com (Lynn)

--00000000000066baa00616bf746f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 23, 2024 at 10:21=E2=80=AFAM Bilge <bilge@scriptfusion.com> wro=
te:

> On 21/04/2024 14:00, Saki Takamachi wrote:
> > 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 unde=
r
> the namespace "PDO=E2=80=9D?
> >
> > e.g.
> > ```
> > PdoMysql =3D> PDO\Mysql
> > PdoPgsql =3D> PDO\Pgsql
> > PdoSqlite =3D> PDO\Sqlite
> > PdoOdbc =3D> PDO\Odbc
> > PdoDblib =3D> PDO\Dblib
> > PdoFirebird =3D> 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=E2=80=9D.
> > 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.

--00000000000066baa00616bf746f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Tue, Apr 23, 2024 at 10:21=E2=80=
=AFAM Bilge &lt;<a href=3D"mailto:bilge@scriptfusion.com">bilge@scriptfusio=
n.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex">On 21/04/2024 14:00, Saki Takamachi wrote:<br>
&gt; Hi internals,<br>
&gt;<br>
&gt; Recently I&#39;ve been working on an RFC regarding object support for =
BCMath. While working on that, I learned of the following RFC:<br>
&gt; <a href=3D"https://wiki.php.net/rfc/namespaces_in_bundled_extensions" =
rel=3D"noreferrer" target=3D"_blank">https://wiki.php.net/rfc/namespaces_in=
_bundled_extensions</a><br>
&gt;<br>
&gt; If we follow this RFC, is it reasonable to place subclasses of PDO und=
er the namespace &quot;PDO=E2=80=9D?<br>
&gt;<br>
&gt; e.g.<br>
&gt; ```<br>
&gt; PdoMysql =3D&gt; PDO\Mysql<br>
&gt; PdoPgsql =3D&gt; PDO\Pgsql<br>
&gt; PdoSqlite =3D&gt; PDO\Sqlite<br>
&gt; PdoOdbc =3D&gt; PDO\Odbc<br>
&gt; PdoDblib =3D&gt; PDO\Dblib<br>
&gt; PdoFirebird =3D&gt; PDO\Firebird<br>
&gt; ```<br>
&gt;<br>
&gt; We&#39;ll probably get a BC Break if try to fix this after 8.4 is rele=
ased, so before it&#39;s released is last chance to fix this safely.<br>
&gt;<br>
&gt; If Tim&#39;s RFC under discussion is passed, the namespace will be &qu=
ot;Pdo&quot; instead of &quot;PDO=E2=80=9D.<br>
&gt; <a href=3D"https://wiki.php.net/rfc/class-naming-acronyms" rel=3D"nore=
ferrer" target=3D"_blank">https://wiki.php.net/rfc/class-naming-acronyms</a=
><br>
&gt;<br>
&gt; I would appreciate hearing your opinions.<br>
&gt;<br>
&gt; Regards,<br>
&gt;<br>
&gt; Saki<br>
<br>
Hi Saki,<br>
<br>
Consider that adding a namespace does not/should not change the class <br>
name. That is, `MyClass` once namespaced becomes `MyNamespace\MyClass`. <br=
>
Ergo, `PdoMysql` becomes `Pdo\PdoMysql`. The class name should still <br>
make sense and be a &quot;strong name&quot; (without conflict) once importe=
d.<br>
<br>
To state it more concretely, I believe it is normal and correct to <br>
include 1-3 namespace components within the class name itself, in order <br=
>
to create such a &quot;strong name&quot;. As a more concrete example of thi=
s, <br>
consider `HttpClient`, `FtpClient` and `SoapClient`. Far too often, we <br>
see user libraries (incorrectly) namespace these as `Http\Client`, <br>
`Ftp\Client` and `Soap\Client` (or similar) where the leaf name just <br>
becomes `Client`. &quot;Client&quot;, by itself is a meaningless moniker, b=
ut that <br>
is all we see once the name is imported, notwithstanding importing <br>
multiple of these clients in one file causes conflicts that now need to <br=
>
be resolved with local aliases. In general, I believe aliasing to be an <br=
>
anti-pattern that points to a failure to create strong names and thus <br>
should be avoided by including some of the namespace portion in the <br>
class name to make the class name more meaningful. Once imported, we do <br=
>
not see the namespace portion within the body of the file any more; <br>
`HttpClient` and `FtpClient` make much more sense by themselves, whether <b=
r>
or not they would otherwise conflict.<br>
<br>
Kind regards,<br>
Bilge<br></blockquote><div><br></div><div>The code base I work in has 25 cl=
asses that are called &quot;Line&quot;. They have namespaces like `App\Mode=
l\Invoice\Line`, this is cumbersome to work with so I would also prefer som=
ething like `Pdo\PdoMysql`, even if it&#39;s not likely to conflict with a =
name such as Mysql.</div></div></div>

--00000000000066baa00616bf746f--