> > I find this proposal to be a backwards step in the age when we are > moving away from resources and their explicit closure. We have > disabled this in PHP 8.0 for curl_close(), imagedestroy(), > openssl_pkey_free(), shmop_close() and xml_parser_free().
Thank you for providing these recent examples of resource-to-object conversions. As you well know, PDO is an object which also optionally uses PHP persistent resources to facilitate connection re-use across PHP requests, a feature which I don't believe has a parallel in object space. Perhaps therein lies a feature request, i.e. to allow an object to be made persistent in the same way a resource can. However, as there is no present path for PDO's conversion away from PHP persistent resources, the prior examples you highlight seem to support an explicit close interface in PDO, in that so long as PHP resources are involved, a close method is warranted. PDO was designed much > better and it deliberately avoided the foot gun that is explicit > connection closure. I'll push back on the notion that disconnect() is likely to be a foot gun. In general, a held PDO object does not guarantee an active connection to a database. Remote connection closures do occur. Networks falter and fail. A robust application necessarily accounts for connectivity failure states, and in the case of PDO, is likely validating the success of every database interaction and reacting accordingly. Considering, an implementation which unwittingly invokes disconnect() and permits continued use of the same PDO for database interactions will at least not error in novel ways. The recommendation for avoiding such mistakes in implementation would be the same which the community has long advocated for - decorate your PDOs. Maybe there are legitimate use cases for this, but > there are also alternatives. I listed a couple use cases in the RFC, which I'll quote below for some added context. * Efficient management of database resources across periods of application idleness, opening and closing connection as needed. * Interoperability with database environment imposing timeout or other session constraints, necessitating multiple connections during script execution. * Abnormal termination procedure in which database closure is highly prioritized, e.g. security violation. * Testing purposes, e.g. simulation of remote connection failure. Pretty much every time I hear the > argument that it would be nice if PDO had it, I can reply with: you > can just design your code in a way that doesn't need it. I tried responding to this in the RFC, also quoted below. PHP makes the implementation of a decorator simple enough through magic methods like __call and __get, but this is complicated in PDO by the PDO statement object, which holds reference to a PDO object, and so must also be reference-managed. A leak-proof decorator should thus override PDO::prepare() and PDO::query() to also prevent the leak of the PDO statement object, likely requiring additional interfaces to otherwise interact with prepared PDO statements, to e.g. bind parameters and execute them, and queried PDO statements, to e.g. fetch one row, N rows, one column, etc. This prescribed implementation pattern is burdensome. For persistent PDO objects, the user has no native capacity to close a connection, given that the database handle is inaccessible and registered as a PHP persistent resource, which remains until the PHP process terminates. To ensure database connectivity across subsequent PHP requests, each new PDO object includes a liveness check on the persistent connection, possibly prompting a new connection. This has meant the burden of defining a viable database connection resides within the database driver's liveness check, and that an outcome differing with actual viability as it concerns a given application results in a non-viable database connection for all subsequent PHP requests. The proposed disconnect() thus grants the user the capacity to declare a connection as no-longer viable.
