Deprecate Proxy interface and related#460
Conversation
| */ | ||
| public function __construct( | ||
| private readonly string $name, | ||
| private array $connections, | ||
| private array $managers, | ||
| private readonly string $defaultConnection, | ||
| private readonly string $defaultManager, | ||
| private readonly string $proxyInterfaceName, | ||
| private readonly string|null $proxyInterfaceName = null, |
There was a problem hiding this comment.
GromNaN
force-pushed
the
deprecate-proxy
branch
from
6aa3123 to
10418db
Compare
| * | ||
| * @phpstan-param class-string $className | ||
| * @phpstan-param CMTemplate $class | ||
| */ |
There was a problem hiding this comment.
This method is never used; last usage removed by
GromNaN
force-pushed
the
deprecate-proxy
branch
from
10418db to
b1273c7
Compare
|
Deprecating those seems too early when the package (and the object manager packages implementing the interface) still have actively maintained versions that support PHP 8.3 and older (and so cannot use native lazy objects unconditionally) |
|
For reference, the ORM triggers its own deprecation warning about using proxies instead of native lazy objects only when running on PHP 8.4+ |
That's what I think too. Deprecations are not triggered directly, but the autoloader will do it. It's mainly to identify classes and interfaces that should no longer be used when native lazy is enabled. |
|
I think it might make sense to say that 4.2.x will be the last 4.x, and to bump to 8.4 so that it's fully OK to have these deprecations. We may even release 5.0.0 before v4 of the ORM, and have ORM v3 be compatible with persistence v5 (and it would crash if you would attempt to use the legacy proxies with persistence v5). Then, on orm v4, we drop compatibility with persistence v4. The upgrade path for people would be:
|
this would imply making 4.1.x a maintained version that could receive patches if needed, unless ORM and ODM both drop support for PHP 8.3 first (so that users of a maintained ORM version on PHP 8.3 are not forced to install an unmaintained persistence version. |
|
Ah yes that's not too great. Maybe this needs to be postponed to 5.1.x then |
GromNaN
force-pushed
the
deprecate-proxy
branch
from
b1273c7 to
31800a5
Compare
GromNaN
force-pushed
the
deprecate-proxy
branch
from
31800a5 to
17fc776
Compare
greg0ire
left a comment
greg0ire
left a comment
There was a problem hiding this comment.
I wrote 5.1 but it does not exist yet, and I think starting a new major with deprecations might be OK in this case.
I also vote for 5.0.0, otherwise we will just release 5.1.0 right after 5.0.0 and the result will be exactly the same. |
Not necessary when using native lazy objects with PHP 8.4+
GromNaN
force-pushed
the
deprecate-proxy
branch
from
17fc776 to
e0c79b4
Compare
|
@GromNaN the difference if you do that is that's it's easier to check that all deprecations that are supposed to be removed are removed before releasing 5. But no big deal anyway |
|
Thanks @GromNaN ! |
Conflicts: src/AbstractManagerRegistry.php doctrine#460 doctrine#458
Conflicts: src/AbstractManagerRegistry.php doctrine#460 doctrine#458
5 participants
Native lazy objects don't need proxy classes. By deprecating interfaces and methods related to proxies, we can spot them more easily in integration and ensure we don't use them when native lazy objects are enabled.