Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:123175 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 3FE351A009C for ; Tue, 23 Apr 2024 09:26:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1713864414; bh=8QpqpgNKIWqKzv/tF43o/lY2RsLWiIh68trDRzquhNs=; h=From:Subject:Date:References:Cc:In-Reply-To:To:From; b=lZBZM83e7Qh4dk51hPKjRPUAAIVsO+dfUUaG25F6GgjYumK3OrvYyfdFTAL0UX4mX zTxKTOXzieey9VBWtVLR4yt/d9DCgyOF/1iNO1IEE+FYNNczzEwMVOpcLUUEU9qe3G hGzXmAbUFqScO2UjrvCzjSkjpUiKBhFabaoXWT6NHaL0xVYD303EON8qFZo0XWNJKp agaYVTzu9C5/ktlQDtHFeSmZILpMudrQWQVuBYuu83vKpVQRF6fL9sWTlt/7lm+sgs txtC/1Y9sqhqQgj/7u5hAk23ON8VbJviDfFrm97autvrZKdrb39IC+VqiG9iReuOuK PQ8ykLa0rk8vg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id CEE67180FF0 for ; Tue, 23 Apr 2024 09:26:53 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: * X-Spam-Status: No, score=1.7 required=5.0 tests=BAYES_50,DMARC_MISSING, HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,MIME_QP_LONG_LINE, MPART_ALT_DIFF,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail1.25mail.st (mail1.25mail.st [206.123.115.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 23 Apr 2024 09:26:53 +0000 (UTC) Received: from smtpclient.apple (unknown [1.124.186.166]) by mail1.25mail.st (Postfix) with ESMTPSA id 5ACA36046A; Tue, 23 Apr 2024 09:26:05 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-E223C285-DB6B-4E94-B1E0-8F88770E414D Content-Transfer-Encoding: 7bit Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net Mime-Version: 1.0 (1.0) Subject: Re: [PHP-DEV] PDO subclass names Date: Tue, 23 Apr 2024 18:55:50 +0930 Message-ID: <0892FAA2-9305-4B52-BA84-440EA6044ABA@koalephant.com> References: Cc: Bilge , internals@lists.php.net In-Reply-To: To: Lynn X-Mailer: iPhone Mail (21E236) From: php-lists@koalephant.com (Stephen Reay) --Apple-Mail-E223C285-DB6B-4E94-B1E0-8F88770E414D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
=
Sent from my iPhone

On 23 Apr 2024, at 18:21, Lynn <kjarli@gmail.com> wrote:<= br>
=EF=BB=BF=


<= div dir=3D"ltr" class=3D"gmail_attr">On Tue, Apr 23, 2024 at 10:21=E2=80=AFA= M Bilge <bilge@scriptfusion.com= > wrote:
On= 21/04/2024 14:00, Saki Takamachi wrote:
> Hi internals,
>
> Recently I've been working on an RFC regarding object support for BCMat= h. While working on that, I learned of the following RFC:
> https://wiki.php.net/rfc/namespaces_in_b= undled_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" in= stead of "PDO=E2=80=9D.
> https://wiki.php.net/rfc/class-naming-acronyms<= br> >
> 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 cla= sses that are called "Line". They have namespaces like `App\Model\Invoice\Li= ne`, 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 n= amespace like MyLib\HTTP\Client is categorically "wrong".

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

```
import MyLib\HTTP;
=

$a =3D new HTTP\Client(...);
```
I'm not claiming that any particular import pattern is more "cor= rect" (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 na= mespaces.

You may as well just go back to MyLib_HTT= P_Client, and ignore that namespaces exist. 
= --Apple-Mail-E223C285-DB6B-4E94-B1E0-8F88770E414D--