Lego: registration.Resource is marked for deprecation - what to use instead?
What should be used instead of the acme.User implementation once registration.Resource has been deprecated?
bouwerp
All 3 comments
@ldez can you please provide some commentary on this?
mxplusb
on 10 Jun 2019
Hi all,
I deprecated registration.Resource because I think it's not a good abstraction of the Account.
For now, I don't have a clear idea about the replacement, but I know that I want to replace it.
Maybe I marked registration.Resource as deprecated too soon but I want to "freeze" changes on this structure to force us to rethink it.
ldez
on 10 Jun 2019
I think it might be good to clarify that the intent is to freeze in the documentation and remove the deprecation warning until you are ready to deprecate it. Since modules provide versioning, if you use the library before the formal deprecation, then you'll be fine with doc strings covering intent, if you use the library after the deprecation, then you'd get the warnings from tooling. It's not a very nice user experience when my IDE throws deprecation warnings for things with no replacements.
mxplusb
on 10 Jun 2019
Related issues
AlbinOS
路
3Comments
moomerman
路
4Comments
kop
路
5Comments
onlyjob
路
3Comments
cruscio
路
3Comments
Most helpful comment
I think it might be good to clarify that the intent is to freeze in the documentation and remove the deprecation warning until you are ready to deprecate it. Since modules provide versioning, if you use the library before the formal deprecation, then you'll be fine with doc strings covering intent, if you use the library after the deprecation, then you'd get the warnings from tooling. It's not a very nice user experience when my IDE throws deprecation warnings for things with no replacements.