Re: PDO subclass names

Sent from my iPhoneOn 23 Apr 2024, at 19:26, Lynn <kjarli@gmail.com> wrote:On Tue, Apr 23, 2024 at 11:26 AM Stephen Reay <php-lists@koalephant.com> wrote:Sent from my iPhoneOn 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.  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.  If the proposal was to have PDO\MySQL\Client, I would be sympathetic to your view. I wouldn't agree with you that it's somehow wrong or hard to use, but I'd be sympathetic. That isn't what's being suggested.  I also don't really see how vendor use is relevant here. What third party userland libraries do is largely just on a whim of whatever new shiny thing PHP-FIG pumps out to feel important. This seems like the wrong place to complain about namespacing practices of vendor libraries.   The PHP RFC referenced applies to bundled php extensions, like... PDO and the various drivers for it.  Using partially imported namespaces and aliases causes inconsistencies that makes it harder to find things. I honestly don't know what you're talking about here.  Nobody here is advocating for MyLibHttpClient class names either. The person you replied to literally said:On 23 Apr 2024, at 17:46, Bilge <bilge@scriptfusion.com> wrote:I believe it is normal and correct to include 1-3 namespace components within the class name itselfMyLibHttpClient easily falls within that description.