PDO subclass names

> > Sent from my iPhone > > On 23 Apr 2024, at 18:21, Lynn <kjarli@gmail.com> wrote: > >  > > > On Tue, Apr 23, 2024 at 10:21 AM 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 >> 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. >

> 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(...); > ```