-
-
Notifications
You must be signed in to change notification settings - Fork 628
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove Field._CHECK_ATTRIBUTE
#2720
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems like a good incremental step to me. i wouldn't even consider this backwards-incompatible since _CHECK_ATTRIBUTE
was private
@lafrech feel free to merge if there's no other changes you plan to make |
I think #2039 (comment) might be the way to go. Not sure I'll carve the time to work on it in the next days, although if my intuition is correct, it might be a nice and complete solution and it may not require so much work. Depends on how eager we are to release. No need to rush IMHO. |
#2039 (comment) sounds like a good plan. no rush on releasing, but i would like to prevent 4.0 from having too many large breaking changes (this is not to discourage implementation of #2039--it's mostly my fault for the 4.0 scope creep 🙃 ). |
Let's hold this this until #2039. I doesn't bring much by itself and might catch people in the wild with fancy setups, like If we go on with #2039, |
sounds good. i think postponing #2039 is a good idea |
@lafrech should we close this PR for now? |
Or make it a draft but I don't think we can do that. I just moved it to 5.0. Keeping it to keep that commit somewhere. We may close it, no big deal. |
woops, this auto-closed when i merged 4.0 into dev and deleted 4.0. We can reopen this when the time comes |
Yeah, no pb, really.
Le 6 janvier 2025 18:33:12 GMT+01:00, Steven Loria ***@***.***> a écrit :
…woops, this auto-closed when i merged 4.0 into dev and deleted 4.0. We can reopen this when the time comes
--
Jérôme
|
This is a first step towards #1046/#2039 (those issues could probably be merged).
It introduces an asymmetry because there is no accessor concept when deserializing.
Ultimately, I'd like to remove those fields. As I suggest in #2039, the accessor method could be passed to any field, so as to combine the capability to customize the accessor (like in
Function
/Method
) and the field feature related to its type (String
,Integer
, etc.).I don't mind postponing this to 5.0 if we're not confident this is the right direction to take and we want to have the full rework complete.