AnnotationRegistry is deprecated but has no alternative in v1.6.1 #270
Comments
|
The idea is that there will be no need to use autoloading at all. We can't
provide an alternative as there ain't any: pre-existing autoloading will
deal with this.
…On Sat, Jun 1, 2019, 01:34 Dane Powell ***@***.***> wrote:
I understand that the AnnotationRegistry is being deprecated and in
version 2+ we should just rely on the Composer autoloader, which is awesome.
However, it seems that at least in version 1.6.1, you can't just use the
autoloader, you still *must* use the registry. I think it's wrong to mark
the registry members as deprecated when no better alternative exists today.
This causes a lot of confusion amongst users and makes downstream
deprecation tests somewhat useless, since there's no way to get them to
pass today.
I think that version 1.x should be changed to allow using the autoloader
for folks that don't want to use the deprecated functions.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#270?email_source=notifications&email_token=AABFVEBAF4JNX27WN52RJ53PYGRXRA5CNFSM4HR6NBN2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GXBY7NA>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AABFVEA3NBN6C2MBFU2QTX3PYGRXRANCNFSM4HR6NBNQ>
.
|
|
Yeah I'm excited that that's the vision for v2, but the problem is that everything's already been deprecated in v1 and there's no alternative in v1. Correct me if I'm wrong. In my mind, the main point of having deprecation warnings is to give folks time to effect a transition between two versions of an upstream library such as annotations. The way that functions have been deprecated in v1.6.1 without providing any viable alternative (that's usable in v1.6.1) subverts that whole purpose. It means that downstream projects will need to be much more tightly coupled to the annotation library version, and can't eliminate the deprecation warnings until after they upgrade to annotations 2.0 (which doesn't exist yet). |
|
Yes, that is correct: specifically, "application" packages will, since libraries have no business in touching the annotation registry. |
As v2 isn't here yet, and looking at doctrine#232 it is unclear if will, and as we have to put up with annoying deprecated functions, here I propose to fall back to the standard autoloader if nothing else worked, and if there's no custom loader defined. Fixes doctrine#270
Libraries do have a business in touching the annotation registry because a typical library is supposed to work out of box. Just And if you have to ask your users to add Overall this is just calling for trouble and endless issues riddled with semantical errors about some inexistent annotations that seeming have nothing to do with the library they're trying to use. Total and complete waste of time. So we, as responsible library authors, have to deal with the annotation registry. |
|
Looks like #271 solves the problem keeping BC. Can we adopt this? |
As v2 isn't here yet, and looking at doctrine#232 it is unclear if will, and as we have to put up with annoying deprecated functions, here I propose to fall back to the standard autoloader if nothing else worked, and if there's no custom loader defined. Fixes doctrine#270
As v2 isn't here yet, and looking at doctrine#232 it is unclear if will, and as we have to put up with annoying deprecated functions, here I propose to fall back to the standard autoloader if nothing else worked, and if there's no custom loader defined. Fixes doctrine#270
* Trigger the standard autoloader as the last resort As v2 isn't here yet, and looking at #232 it is unclear if will, and as we have to put up with annoying deprecated functions, here I propose to fall back to the standard autoloader if nothing else worked, and if there's no custom loader defined. Fixes #270 * Do not use standard autoloader with registerFile() * Add tests for fallback autoloading * Update deprecation messages * Update AnnotationRegistry.php Co-authored-by: Andreas Braun <git@alcaeus.org>
I understand that the AnnotationRegistry is being deprecated and in version 2+ we should just rely on the Composer autoloader, which is awesome.
However, it seems that at least in version 1.6.1, you can't just use the autoloader, you still must use the registry. I think it's wrong to mark the registry members as deprecated when no better alternative exists today. This causes a lot of confusion amongst users and makes downstream deprecation tests somewhat useless, since there's no way to get them to pass today.
I think that version 1.x should be changed to allow using the autoloader for folks that don't want to use the deprecated functions.
The text was updated successfully, but these errors were encountered: