Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:123176 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 E76051A009C for ; Tue, 23 Apr 2024 09:41:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1713865308; bh=+32IwG8RLLZPV9rlmIWmdahnM79aomRd2AaQcMox2m4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=UtTmFzC4iKPZyOtTpKybqwhcvYF7iL02brv1E4deDCo2H4kW0F2EByHOnMsKi3HQf HUlaqXL8c6dcbWAxnjAiz0umXhUw2tRo6PED2vxP+COI5EufNt0Xv8UjUFgsB4VXhO 00fXE1gzc9iEDlilcD33gk45ATeZTSD6U2gTQAnkW+5Tg4qpCQAKP9KtUOm7UH3HIh Xn/lH0M1lT+m4fEfeXNSIotk8cqUjUZBvUTz1cLch6XrhqKHRNLeglW6lDi67CiksR /Yw3g5SgS8+MDxPaMsW2t3VnrIQon4FuhKmHb8SmFaBjqR9YZPV9l9QSIWBzEW0V5n fe7wyTRqVQKpg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 5E7B71810B7 for ; Tue, 23 Apr 2024 09:41:47 +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=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,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 mail-ed1-f49.google.com (mail-ed1-f49.google.com [209.85.208.49]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 23 Apr 2024 09:41:46 +0000 (UTC) Received: by mail-ed1-f49.google.com with SMTP id 4fb4d7f45d1cf-56e477db7fbso8716055a12.3 for ; Tue, 23 Apr 2024 02:41:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713865266; x=1714470066; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+32IwG8RLLZPV9rlmIWmdahnM79aomRd2AaQcMox2m4=; b=G4+hpQz/VB6fBlW/hFNyyugNBvVwCXXsGkKFtJND5LRj5HW1Iyt1wV9xpEX5cmIk1R LAwtVJHBaZfT861FpurPr5V9Uj9JKVXxjX2KQOV1urd0yUXacdHj54IQA5QD0BdqjXhN mKf2hnjtgC/07jXNaSg5P6tn1Lis9RwJ1v4PqZAlxHQTrx7Ho45uTkgYXD46tfedos55 lGboqq13Nvp29ZAgOB5PC4S+2tkosAJyigZZiWjrvkALzoOvygofO3OK5Lr2afo+jEG6 +pIHVsBQHEP22VEIvHRGnuXnE96rZ4BbtuWYkAYU2Hjf/KfIffox+GGV9YUIvnXlRIGI yOjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713865266; x=1714470066; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+32IwG8RLLZPV9rlmIWmdahnM79aomRd2AaQcMox2m4=; b=ALW5txfSXGcPfrQPXGqYpsb1oQsoC6e+kaPhl/iE+eC+Bkj/IvUvYjEoXSGqTbzEJk 2ukrEkniyc9uPYR8J/bGXiDAl9nIfC0a1zFCfbCAaT+q1Ae0fICG+9psm/HoJL9gXkZ5 NBGHlISo6tgzYh6FErXvU3BegK1w9CdYBPZ6UnRFobc0nONIrOcWv625ShPGzU+V+oaA /1FmeAk2RUJQhrs9AGRtICztxKSzkvP70naJdREM1xAvgeuCAR2/6gi5YRPF4Vxmnk76 zqzxZd4M+RYCzTo5ljxIj9ioOIvV1q1AL2PUwaFJTHzLxv5i21pfecgmwWFFaHAesUz1 Hxxw== X-Forwarded-Encrypted: i=1; AJvYcCWAIJEELd/rYEZNC0n5K1u+UYhS3hA9ZmM1J0J2zmS17rcizMnaK7KzZYrf8cwrQ5MQPvEm0LWI2Q4wuOF0mIXFYwW07c4L8g== X-Gm-Message-State: AOJu0Yx/1Y9EmpCuffejjr/tSRxxKx5FiRu5T/tPYIbfk2uoCHfafChD JPaKUGlGF7hY6tsBHZ3EoCP1uFiK3vxP5Z5Qte0o2vY00JC6Ogd85VMcsFO4j42qjVOo9pPPRKC VO3wJMQ2zmALphJHeibHiUL8BVvGTdQ== X-Google-Smtp-Source: AGHT+IE2xWKlPxknAcoXHx3ELpGW/iiUFD/5yqFbHPpRJqUSf5R1UAQHED41k0q6FlxGEfyhk4K0utvcdPWyINIf09c= X-Received: by 2002:a17:907:e8d:b0:a55:b784:c307 with SMTP id ho13-20020a1709070e8d00b00a55b784c307mr4283385ejc.11.1713865265516; Tue, 23 Apr 2024 02:41:05 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 References: <0892FAA2-9305-4B52-BA84-440EA6044ABA@koalephant.com> In-Reply-To: <0892FAA2-9305-4B52-BA84-440EA6044ABA@koalephant.com> Date: Tue, 23 Apr 2024 11:40:38 +0200 Message-ID: Subject: Re: [PHP-DEV] PDO subclass names To: Stephen Reay Cc: Bilge , internals@lists.php.net Content-Type: multipart/alternative; boundary="000000000000581ceb0616c05afd" From: kjarli@gmail.com (Lynn) --000000000000581ceb0616c05afd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 23, 2024 at 11:26=E2=80=AFAM Stephen Reay wrote: > > Sent from my iPhone > > On 23 Apr 2024, at 18:21, Lynn wrote: > > =EF=BB=BF > > > On Tue, Apr 23, 2024 at 10:21=E2=80=AFAM Bilge w= rote: > >> 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 >> under 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. > > > 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 s= o > wish: > > ``` > import MyLib\HTTP; > > $a =3D new HTTP\Client(...); > ``` > > I'm not claiming that any particular import pattern is more "correct" (an= d > I think it's a bad idea to suggest that other usage patterns are > "incorrect") but adding repetitive prefixes kind of defeats the purpose o= f > 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. --000000000000581ceb0616c05afd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Apr 23, 2024 at 11:26=E2=80= =AFAM Stephen Reay <php-list= s@koalephant.com> wrote:

Sent from my iPhone

On 23 Apr 2024, at 18:21, Lynn <<= a href=3D"mailto:kjarli@gmail.com" target=3D"_blank">kjarli@gmail.com&g= t; wrote:

=EF=BB=BF


On Tue, Apr 23, 2024 at = 10:21=E2=80=AFAM 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 = 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 und= er 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 rele= ased, so before it's released is last chance to fix this safely.
>
> If Tim's RFC under discussion is passed, the namespace will be &qu= ot;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 importe= d.

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 thi= s,
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, b= ut 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


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

The argument that "Client" is meaningl= ess becomes pretty moot when you realise that you can import a *namespace* = and use it relatively, if you so wish:=C2=A0

```
import MyLib\HTTP;

$a =3D 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.=C2=A0

--000000000000581ceb0616c05afd--